Re: shared library support hookin the remote.c

[Kevin Buettner <kevinb@redhat.com>]

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.

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.

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

Kevin