Re: shared library support hookin the remote.c

[Andrew Cagney <cagney@gnu.org>]

> On Fri, 02 Jul 2004 18:25:22 -0400
> Andrew Cagney <cagney@gnu.org> wrote:
> 
> 
>>>> > On Fri, 02 Jul 2004 16:20:19 -0400
>>>> > Andrew Cagney <cagney@gnu.org> wrote:
>>>> > 
>>>
>>>>>> >>> Kevin, how does/should the existing remote GNU/Linux target work?
>>>>>> >>> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
>>>>>> >>> components interact to maintain the shlibs?
>>>
>>>> > 
>>>> > 
>>>> > The existing GNU/Linux target knows just enough about the dynamic linker
>>>> > (struct layout and symbol names) to be able to use memory reads to do the
>>>> > entire thing.  I.e, all the information that GDB needs is either obtained
>>>> > from the symbol table or from the address space of the target.
>>
>>> 
>>> So, from the below, there's also an event bound to a breakpoint that 
>>> triggers the entire thing?
> 
> 
> Yes.
> 
> 
>>>> >     a) The unrelocated starting address of a segment.
>>>> >     b) The length of the segment
>>>> >     c) The address (relocated) of the segment.
>>>> >     d) The address space associated with the segment (think harvard
>>>> >        architecture here).
>>>> >     e) A way of iterating over the various segments.
>>
>>>        f) object file path
> 
> 
> Yes (thanks), I forgot that one.
> 
> 
>>> For the /proc and SVR4 cases, did any of this information come from the 
>>> object file?
> 
> 
> No.  The object file may appear to contain similar information (i.e. 
> section addresses and lengths).  As noted below, the information
> contained in (a)-(f) is used to generate relocation data for loading
> an object file.

An object file (at least elf) contains segment information.  I guess 
this is ignored?  (For those that are wondering, there's a subtle 
difference between segment and section :-).

> You will see solib-svr4.c consulting the object file.  It does this
> to learn of certain addresses needed to location the above mentioned
> information and for the address upon which to set a breakpoint.
> 
> 
>>> Did you have a particular harvard architecture in mind?
> 
> 
> No.  We just need to provide for a way to distinguish between
> potentially overlapping addresses.  If this is encoded in the address
> in such a way that there can never be any ambiguity, then field (d) is
> not needed.  I'm not convinced there's any way to guarantee this
> though, which is why I suggested a separate field.

Can we worry about this when it becomes a problem?

>>> I'm still not clear whats done with the information in this table once 
>>> its created.
> 
> 
> It is used to generate relocation data for loading an object file's
> symbols.  (See the call to symbol_file_add() in solib.c.)  Given a
> segment obtained from (a)-(f), we need to find the corresponding
> object file and sections.  We can then compute a relocation constant
> by subtracting (a) from (c) to apply (add) to addresses associated
> with each of the affected sections.

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

Andrew