From: Daniel Jacobowitz <drow@mvista.com>
To: gdb@sources.redhat.com
Subject: Re: hacking shlib/dlopened breakpoints
Date: Fri, 21 Nov 2003 16:34:00 -0000 [thread overview]
Message-ID: <20031121163457.GA27120@nevyn.them.org> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2003-11-21 16:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-21 12:55 Caolan McNamara
2003-11-21 16:34 ` Daniel Jacobowitz [this message]
2003-11-21 19:15 ` H. J. Lu
2003-11-21 19:16 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031121163457.GA27120@nevyn.them.org \
--to=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox