Re: shared library support hookin the remote.c

[Kevin Buettner <kevinb@redhat.com>]

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.

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.

I think we need the following:

1) A way to be notified when the shared library mappings have changed
2) A way to fetch the new mappings.  I think the following should
   be sufficient:
    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.

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.

Kevin