Re: Shared libraries and the solib interface

[Kevin Buettner <kevinb at redhat dot com>]

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

> Kevin Buettner wrote:
> 
> >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.]
> 
> Do you know of an example of this?

No.  I thought of it last night as I was typing the first part of the
explanation.  If you wind up doing it this way, I'll be very
interested to see how it turns out.

> And a second question is how does a 
> generic stub inform the GDB (workstation side) app which shared library 
> got loaded and where or is this not necessary?

For svr4- and sunos-like shared library support, this information is
available by examining the target's memory.

If this sort of mechanism is not available for your target, I suggest
one of two approaches:

    1) Add new 'q' packets for fetching the information.

    2) Use the qRcmd packet for fetching it.

The difference between these two approaches is subtle, because either
way you'll have to devise and adhere to some sort of protocol for
fetching the library information.  However, with option 1 (new 'q'
packet(s)), you'll have to submit a proposal for the suggested
protocol changes for public inspection and commentary.  It could take
quite some time to finalize the protocol specification.  E.g, take a
look at the interaction that took place with regard to Daniel
Jacobowitz's recent thread packet proposals.

The qRcmd approach will likely be quicker/easier to do because the
interface you devise can be private between GDB's solib backend and
the stub.

My suggestion is to start with qRcmd and see how the implementation
turns out.  With that under your belt, you may then be in a better
position to suggest a specification for a set of shared library
specific 'q' packets.

Kevin