Re: [PATCH] bfd function for chasing .gnu_debuglink

[graydon hoare <graydon at redhat dot com>]

On Wed, 2003-01-29 at 14:21, Daniel Jacobowitz wrote:

drow! hey, long time no see..

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

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

-graydon