Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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