Re: shared library support hookin the remote.c

[Kevin Buettner <kevinb at redhat dot com>]

On Thu, 08 Jul 2004 11:03:54 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> > 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 :-).

To the best of my knowledge, GDB doesn't currently use the segment
information contained in an executable.

> > 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?

Well, if we're trying to develop a protocol, we ought to at least make
it extensible so that it'll handle this case if/when it becomes a
problem.  Aside from this concern, I have no objection to leaving it
until later.

> >>> 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.

Yeah, this should be the segment offset from the executable.

>  >>>> >     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?)

I don't think this is really needed.  Though having it wouldn't hurt
if you want an additional check to make sure that you've found an
appropriate section.

>  >>>> >        architecture here).
>  >>>        f) object file path
> 
> How does this compare to what is found in /proc/*/*map*?

I'm not sure where you're going with this.

It's useful to have the original segment address and length in order
to find the corresponding sections.  If you don't have this
information, you have to try to determine it by playing games with
things like the protection mask or perhaps the order of the entries in
the map file.  I've done this before on AIX/IA64 and it was not fun.

It's not at all clear to me though what any of this has to do with
Stephen's orignal question.

Kevin