This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Introduce solib_loaded observer


   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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]