Re: shared library support hookin the remote.c

["Stephen P. Smith" <ischis2@cox.net>]

Andrew Cagney wrote:

>> The system that I am working on has an OS that is used for embedded 
>> applications.  Therefore the only
>> way to debug is by a remote protocol or by emulator.  The host type 
>> is either i686-pc-elf or
>> powerpc-motorola-elf
>>
>> As for native on my host - usually I am running on my cygwin box and 
>> things are working fine there.
>
>
> But assuming you could, what mechanisms would you use to implement it? 
> :-) 


Sorry, but I had to modify the old (non-gdb supported) implementation 
which had a side benifit of reminding me
what needed done.  Note that I am not saying that this has to be the 
protocol, just that I know it works with a minimal
amount of network bandwith.  Also note, that because of number 2 below, 
this support is backward compatible to older
stubs or to future stubs that don't care to support shared libraries.

1) Send a packet to the remote target asking if there are any shared 
libraries. 

2)  If the target sends back a '\0', then GDB knows that the target 
doesn't support this protocol and won't
and the rest of this protocol is unused for the remainder of the 
debugging session.  This keeps the traffic to a
minimum for stubs that don't support shared libraries (and we have a 
couple).

3) If the stub supports Step 1 it replies with a flag character.  We 
used '0' for none and '1' to not that there are some.

4)  If a '1' is returned in Step 3, then the following happens until 
there are no more libraries to  report.  The stub will only
     return the information for one shared library at a time so as not 
to over run a buffer in GDB.
 
      - a packet is sent asking for the shared library information.
       - The stub returns the library name and its location in memory 
which GDB uses to then load the symbol table correctly.

There are a couple of things that should be taken into acount for remote 
stubs.
1)  The remote OS may not provide a way for the stub to get an 
interrupt  or hook the library loading code but some may.  The
     OS I am involved with has that code in read-only memory.
2)  The OS may have already loaded the libraries by the time the stub 
gets control of the the process. 

It is for these two reasons that we don't use the breakpoint method that 
kevin is talking about.  I do like it for systems that can
support it - however.

sps

sps