This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: shared library support hookin the remote.c
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Stephen & Linda Smith <ischis2 at cox dot net>, gdb at sources dot redhat dot com
- Date: Fri, 2 Jul 2004 16:22:10 -0700
- Subject: Re: shared library support hookin the remote.c
- Organization: Red Hat
- References: <40AD1DA8.3090809@cox.net><40AE69AB.7000004@cox.net><20040611141424.2bed79f7@saguaro><40DA349C.6080607@cox.net><20040628134303.20e1cff0@saguaro><40E09084.70108@cox.net><20040628172120.2844044d@saguaro><40E0CC21.1020401@cox.net><20040701105812.44b85b9b@saguaro><40E5C383.7060506@gnu.org><20040702142522.038721dd@saguaro><40E5E0D2.70205@gnu.org>
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