Re: Shared libraries and the solib interface

[Kevin Buettner <kevinb@redhat.com>]

On Oct 1,  9:11pm, Stephen Smith wrote:

> I am thinking of working on using writing a solib-remote.c interface 
> file to implement loading of shared libraries.  I believe that this is 
> what Kevin suggested a couple of years ago, but I was too stuborn and 
> dropped it.  The item that I am confused about is how to have the remote 
> box (which uses the current remote protocol) communicate back to the 
> host the fact that a shared library has been loaded.  Does anyone have 
> suggestions?

One common way of doing this is to have gdb place a breakpoint in some
function which is called when there's a change in the set of shared
libraries that the target has loaded.  This is usually just a stub
that the dynamic linker provides explicitly for this purpose.  Then,
when that breakpoint has been hit, gdb can query the target for a list
of loaded shared libraries.  If the stub can tell gdb specifically
which libraries have just been loaded, so much the better.  As I
recall, the loading is not distinguished from unloading, so gdb
usually (always?) just fetches the entire list of currently loaded
shared libraries from the target.

This approach can be used even if the dynamic linker doesn't provide a
convenient function (or even an inconvenient function) to set a
breakpoint on.  In such a case, the stub is presumably informed via
other means of the fact that a shared library has just been loaded. 
The stub could stop and tell GDB that it's just hit a fake "shared
library loaded" breakpoint.  Your solib backend (on the GDB side) and
the stub would have to agree on some suitable address to use for this
purpose.  There is some risk associated with lying to GDB in such a
manner, but this risk is mitigated by the fact that users don't
usually stop at these internal breakpoints.  [Setting
``stop-on-solib-events'' does allow the user to stop though.  Once you get
the basic machinery going, you'll want to remember to test with this
setting to make sure it's not too badly broken.  It can, at times, be
extremely useful to allow a user-level stop when a solib related
breakpoint has been hit.]

There are other approaches that could be used, but most of these would
involve adding code to other (generic) portions of gdb.  Since it's
more difficult to get approval for changes to generic code, it's probably
best to stick with mechanisms which are already in use by other targets.

HTH,

Kevin