Re: Shared libraries and the solib interface

[Stephen & Linda Smith <ischis2@cox.net>]

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?  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?

>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.
>  
>

Yeah, that's where I crashed and burned last time.

>HTH,
>
>Kevin
>
>
>  
>