Re: [PATCH] bfd function for chasing .gnu_debuglink

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Jan 30, 2003 at 06:38:55PM -0500, graydon hoare wrote:
> On Wed, 2003-01-29 at 14:21, Daniel Jacobowitz wrote:
> 
> drow! hey, long time no see..

Sure has been.

> > It would be nice from my perspective if this were transparent; if the
> > sections from the secondary object file were simply added to the bfd
> > for the first object, and handling two file descriptors was seamless
> > inside opncls.c instead of the application doing it.  Then you could
> > just iterate over the list of sections and find the new debug info,
> > with no further effort.
> 
> yes, this would be nice. I spent the latter half of today probably
> re-discovering why this was rejected in the case of GDB. I got it
> working with the "pure" debugging sections (.debug*), but unfortunately
> when you iterate over a BFD's section list, it *doesn't* include the
> .symtab section. it seems that since .symtab has "symbols" in it, it is
> magic as far as BFD is concerned, and is handled separately within the
> backend. worse, there doesn't seem to be much of a general way of
> merging symbols from one BFD into an existing one; you can queue them up
> for writing to a *fresh* BFD, but I think that would mean doing a full
> re-linking pass over each bfd_openr'ed file, writing into an in-memory
> BFD. I don't think that behavior would be a welcome "transparent"
> addition to BFD :)

Oh, lord.  Is the symbol table in the separate debug file a strict
superset?  i.e. could we use that one instead of playing with merging?

> > Also, I'd want the DEBUGDIR thing to relocate a la sysroot; but I don't
> > think that's possible if it's directly in BFD.  I'll think about it.
> 
> I don't know precisely what you mean; a default is wired in with
> configury, but the caller can override by providing their own string
> (gdb has a command-line flag so non-root users can haul in debug
> packages from their home dir).

I just don't really like hardwired paths in libraries.  See all the
contortions with make_relative_prefix I added to ld recently.  But it's
not a big deal; each client can do the same thing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer