Re: shared library support hookin the remote.c

Stephen P. Smith
2004-07-13T00:19:39Z

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