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


  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