Re: shared library support hookin the remote.c

[Andrew Cagney <cagney at gnu dot org>]

> 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