This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: hacking shlib/dlopened breakpoints
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 21 Nov 2003 11:34:58 -0500
- Subject: Re: hacking shlib/dlopened breakpoints
- References: <20031121125502.GA7194@skynet.ie>
On Fri, Nov 21, 2003 at 12:55:02PM +0000, Caolan McNamara wrote:
> I'm looking at breakpoints in dlopened libraries at the moment,
> setting a breakpoint after my library is dlopened works of course
> and, as in the example below, I see that gdb can move the address of
> the breakpoint in the .so when it is unloaded and reloaded during
> execution, but on re-execution of the little program I get
> "
> Warning:
> Cannot insert breakpoint X.
> Error accessing memory address 0xe8535a: Input/output error.
> "
>
> Naturally the library isn't loaded at the start of re-execution, but I
> hoped that the the breakpoint state would change to bp_shlib_disabled
> and get reenabled when the .so reappears.
>
> So I dig a little and see that this will only happen if
> (DISABLE_UNSETTABLE_BREAK (b->address)) is true. But that queries to
> see if the address is a valid loaded address, which it isn't anymore.
> I naively turned this to if (1) to see what would happen, and was
> happy to see this worked, the breakpoint in the .so gets re-enabled
> and set to its new address when the affected .so reappears, and gdb
> stops in it correctly.
Could you try a current CVS snapshot? I just made a change in this
area to fix another problem with dlopen'd librares.
> But sadly when I continue everything only works as far as the dlclose
> of that .so where I get...
> Program received signal SIGSEGV, Segmentation fault.
> Cannot remove breakpoints because program is no longer writable.
> It might be running in another process.
> Further execution is probably impossible.
> 0x008c4ea4 in _dl_debug_state_internal () from /lib/ld-linux.so.2
>
> Any ideas/hints as to how to make it work, or what exactly might the
> cause of my exciting crash above ? The reason I'm fiddling with this
Probably something else was loaded over the same space. Or GDB's
breakpoint list got hosed.
> is that I'm really after a working deferred break/future-break in gdb
> to make debugging apps like OpenOffice/Mozilla with mountains of
> dynamically loaded components a lot easier.
See Jeff's recent post on this topic...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer