From: Mark Kettenis <kettenis@gnu.org>
To: drow@false.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Introduce solib_loaded observer
Date: Tue, 11 Jan 2005 21:57:00 -0000 [thread overview]
Message-ID: <200501112157.j0BLvDp9000926@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20050109230629.GA4612@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 9 Jan 2005 18:06:29 -0500)
Date: Sun, 9 Jan 2005 18:06:29 -0500
From: Daniel Jacobowitz <drow@false.org>
On Sun, Jan 09, 2005 at 11:58:18PM +0100, Mark Kettenis wrote:
> Date: Sun, 9 Jan 2005 17:37:33 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Sun, Jan 09, 2005 at 02:05:15PM +0100, Mark Kettenis wrote:
> >
> > Calling the observer after loading the symbols isn't possible. You
> > can set "auto-solib-add" to 0, and then the symbols will never be
> > loaded at all. So you'll always have to force loading the symbols
> > from within your observer anyway (but you only have to do so for the
> > threads library). From a code perspective the point where the
> > notification is called is the most logical. And that way it's less
> > likely that we see "auto-solib-add" related bugs ;-).
>
> At the same time, I worry that it's going to be confusingly
> inconsistent - for instance, I would have expected turning off
> auto-solib-add to prevent loading symbols for libpthread! Or at least,
> loading of full symbols (all libthread_db on GNU/Linux really needs are
> a couple of minsyms).
>
> We should try to be as consistent as possible. The current situation
> is very inconsistent too: if you turn off auto-solib-add, you won't
> get thread debugging support. It's true that for debugging support
Note that there's no other way to deliberately turn off thread
debugging at present.
Then we should add a command to do that.
> you usually only need a few minimal symbols. I considered rolling my
> own BFD-based lookup function, but I suspect that would result in a
> serious performance hit because I'd lose the benefit of caching.
I doubt it would be that serious. It'd be a bit tricky, of course, so
adding extra code for it seems like a shame. Perhaps we could read in
just the minsyms...
...perhaps another threads implementation needs full symbols. The
bottom line is that the code probably needs to fiddle with symbols,
whether or not we call the observer before or after GDB would normally
load the symbols for a shared library.
> Because of the auto-solib-add issue I don't think it is, but given the
> right arguments I think you can make me think differently. What to
> the others think of this?
I wonder if we can envision any other potential consumers for this
hook? What would they want to do?
The observer could be used to re-set breakpoints in shared libraries,
to implement bp_catch/bp_unload in a somewhat more generic fashion.
Some of these might need symbols some of them don't.
I'm still in favour of calling the observer *before*. That way,
people using the observer are forced to ask the question whether they
want symbols to be loaded or not.
Mark
next prev parent reply other threads:[~2005-01-11 21:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-08 23:14 Mark Kettenis
2005-01-09 0:01 ` Daniel Jacobowitz
2005-01-09 13:05 ` Mark Kettenis
2005-01-09 22:37 ` Daniel Jacobowitz
2005-01-09 22:58 ` Mark Kettenis
2005-01-09 23:06 ` Daniel Jacobowitz
2005-01-11 21:57 ` Mark Kettenis [this message]
2005-01-12 1:09 ` Daniel Jacobowitz
2005-01-11 21:15 ` Kevin Buettner
2005-01-09 4:40 ` Eli Zaretskii
2005-01-09 11:01 ` Mark Kettenis
2005-01-12 20:49 ` Mark Kettenis
2005-01-13 4:38 ` Eli Zaretskii
2005-01-10 16:21 ` Andrew Cagney
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=200501112157.j0BLvDp9000926@elgar.sibelius.xs4all.nl \
--to=kettenis@gnu.org \
--cc=drow@false.org \
--cc=gdb-patches@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