Re: shared library support hookin the remote.c

Kevin Buettner
2004-07-02T23:22:18Z

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