Re: Shared libraries and the solib interface

Re: Shared libraries and the solib interface

[John S. Yates, Jr.]

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

I don't have suggestions, but I do have a keen interest in this effort.
I have implemented an RSP stub for our embedded environment.  A key
aspect of our system is broadcasting small snippets of code to an army
of worker nodes.  That code is processed by a very minimal loader and
then executed.  I would LOVE to provide my user community an automatic
means of debugging such downloaded code.

/john
--
John S. Yates, Jr.   508 665-6897 (voice)
Netezza Inc          508 665-6811 (fax)
200 Crossing Blvd.   Framingham, MA 01701

Shared libraries and the solib interface

[Stephen & Linda Smith]

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?

Andrew - are you the one I need to work with on protocol questions and 
is Kevin still the one to work with on the solib interface?

Re: Shared libraries and the solib interface

[Kevin Buettner]

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

Re: Shared libraries and the solib interface

[Stephen & Linda Smith]

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

Re: Shared libraries and the solib interface

[Kevin Buettner]

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

Re: Shared libraries and the solib interface

[Stephen P. Smith]

Kevin Buettner wrote:

>>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.
>  
>
It is available.  I guess I didn't explain well enough.  

Given that I know where/what is loaded on the target machine which is 
running gdbserver,  how do I communicate to the workstation running gdb 
to load the symbol file  and the addresses of the various sections?

sps

Re: Shared libraries and the solib interface

[Kevin Buettner]

On Oct 2,  1:50pm, Stephen P. Smith wrote:

> Kevin Buettner wrote:
> 
> >>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.
> >
> It is available.  I guess I didn't explain well enough.  

Oh!

> Given that I know where/what is loaded on the target machine which is 
> running gdbserver,  how do I communicate to the workstation running gdb 
> to load the symbol file  and the addresses of the various sections?

That's already handled by the existing (generic) shared library code. 
See solib.c.

Kevin

Re: Shared libraries and the solib interface

[Andrew Cagney]

> 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?
> 
> Andrew - are you the one I need to work with on protocol questions

Yes.  The thing to do is figure out what you want to transfer between 
the host/target and then I can help with the protocol.

So you and Kevin are both clear on the process.  The protocol change is 
first taken to the point where it "looks ok" and "appears to work".  It 
is then posted to gdb@ as a formal proposal (given at least a week with 
allowances for holidays).    This formalization step is important, it 
ensures that people (including me :-) don't shoe-horn poorly thought out 
protocol changes when no one is looking. You'll see DanielJ's vCont 
packet is now in that final review phase.

Andrew