Date: Tue, 22 Oct 1996 07:35:39 +1000 From: Bruce Evans <bde@zeta.org.au> To: jdp@polstra.com, msmith@atrad.adelaide.edu.au Cc: freebsd-current@freebsd.org Subject: Re: kern/1848: breakpoints in shared libraries don't fire Message-ID: <199610212135.HAA29513@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>The text segment starts out read-only. GDB does (or at least did) >change the protections to read/write as needed when it has to insert a >breakpoint. As John-Mark Gurney pointed out in a different posting, >this all used to work just fine. If it's broken now in -current, then >it's probably a problem with gdb. > >I just checked it on a current from just a few days ago, and it works >fine for me. I was able to set a breakpoint on gethostbyname() in libc, It's broken somewhere in vm now. procfs_domem() returns 0 without writing anything, as if for EOF. (procfs_rwmem() gets to the (writing && object->backing_object) case. Then m == 0 and vm_fault() returns 0, but the faulted-in page is not used.) ptrace() seems to be broken even for putting a breakpoint at _main. This is fixed by retrying, and gcc retries with PT_WRITE_D after PT_WRITE_I fails. gcc starts with PT_WRITE_D for the shared library (this is reasonable because the shared library is above _etext) and it doesn't retry (this is reasonable because ptrace() doesn't return -1, unlike for _main). In a test program, neither PT_WRITE_I nor PT_WRITE_D works the first time, ands no combination works the second time for the page after _etext, but ptrace() correctly returns -1 for all failures. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610212135.HAA29513>