This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] bfd function for chasing .gnu_debuglink
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