Re: shared library support hookin the remote.c

Andrew Cagney
2004-07-02T22:25:35Z

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

> I am comfortable with this arrangement for GNU/Linux, but it isn't
> adequate for all shared library scenarios. E.g, I've worked on shared
> library mechanisms in the past which used files from /proc to specify
> the mappings. It would be good if we could come up with a protocol
> extension whereby the target supplies the information that GDB
> needs.

(See qPart)

> 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

For the /proc and SVR4 cases, did any of this information come from the
object file? Did you have a particular harvard architecture in mind?

I'm still not clear whats done with the information in this table once
its created.

> solib-svr4.c does (1) by using breakpoints; i.e. a breakpoint is set
> on a dynamic linker function which is always called when the mappings
> change. It does all of (2) by reading target memory.

Andrew