Re: shared library support hookin the remote.c

[Andrew Cagney <cagney@gnu.org>]

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