Re: shared library support hookin the remote.c

Andrew Cagney
2004-07-08T15:04:10Z

> 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