This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: shared library support hookin the remote.c


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]