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
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.
An object file (at least elf) contains segment information. I guess
this is ignored? (For those that are wondering, there's a subtle
difference between segment and section :-).
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.
Can we worry about this when it becomes a problem?
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.
So its:
- an event indicating that the link map changed
- in responce the solib code fetches the entire link map
- the link map is merged against the current local cache
- the objfile code is notified of any segment changes
It can be sliced 'n' diced at least two ways:
- at the objfile interface -> the protocol pushes changes to the link map
- a the solib interface -> the protocol pushes a ``something solib like
happened'', and then the solib code pulls the link map. If things are
being done at this lower level, the protocol could even pass across the
address/symbol at which the link map breakpoint should be inserted?
As for the information:
>>>> > a) The unrelocated starting address of a segment.
Is this the offset in the object file.
>>>> > b) The length of the segment
>>>> > c) The address (relocated) of the segment.
>>>> > d) The address space associated with the segment (think harvard
Rather than this is the protection mask needed (r,w,x?)
>>>> > architecture here).
>>> f) object file path
How does this compare to what is found in /proc/*/*map*?
Andrew