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
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: graydon hoare <graydon at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 29 Jan 2003 14:21:12 -0500
- Subject: Re: [PATCH] bfd function for chasing .gnu_debuglink
- References: <1043801222.9286.122.camel@dub.venge.net>
On Tue, Jan 28, 2003 at 07:47:01PM -0500, graydon hoare wrote:
> Hi,
>
> A change recently entered GDB to support "separate debug info". This
> permits shipment and installation of smaller, stripped binaries, with
> secondary packages (on secondary media) to support users who care about
> debugging symbols. This trick is accomplished by embedding a filename
> and checksum in a special ".gnu_debuglink" section of an object, which
> specifies another object containing *only* the debug symbols for the
> first. GDB then merges these symbols, as though they were present in the
> initial object.
>
> It has become clear recently that GDB is not the only program which
> would benefit from these separate packages; notably objdump and the
> oprofile post-processing tools require access to them. Rather than
> duplicate the same section-extracting, path-searching and
> checksum-matching code in these tools, it was suggested that we
> centralize the feature in binutils itself.
>
> Attached it a patch to BFD which adds such a function. The comments give
> a pretty clear overview of its use. Configury also needs to be rebuilt,
> of course.
>
> Any BFD maintainers interested in pulling this in?
Just a thought - and I realize this is similar to what we asked you to
do over in GDB and probably even more of a nuisance, so I'm not going
to insist.
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.
There's probably major complications I haven't thought of in doing it
that way.
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer