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.