Re: shared library support hookin the remote.c

Andrew Cagney
2004-07-14T18:08:19Z

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

Good :-)

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

So each time the inferior stops, GDB will need to re-poll for shlib changes?

Can the stub instead generate a packet, very like the recently added F
(File I/O) indicating that the link map changed (and what)?

I previously wrote:

> So its:
>
> - an event indicating that the link map changed
> - in responce the solib code fetches the entire link map
> - the link map is merged against the current local cache
> - the objfile code is notified of any segment changes
>
> It can be sliced 'n' diced at least two ways:
>
> - at the objfile interface -> the protocol pushes changes to the link map
>
> - a the solib interface -> the protocol pushes a ``something solib like happened'', and then the solib code pulls the link map. If things are being done at this lower level, the protocol could even pass across the address/symbol at which the link map breakpoint should be inserted?
>
> As for the information:
>
>>>>> > a) The unrelocated starting address of a segment.
>
> Is this the offset in the object file.
>
>>>>> > b) The length of the segment
>>>>> > c) The address (relocated) of the segment.
>>>>> > d) The address space associated with the segment (think harvard
>
> Rather than this is the protection mask needed (r,w,x?)
>
>>>>> > architecture here).
>>>> f) object file path
>
> How does this compare to what is found in /proc/*/*map*?

The other is to have a custom xxx-shlib hooked up to inferior stopped
that queries for the stuff you describe. It could probably be tunneled
as a TARGET_OBJECT_KOD packet.

Andrew