This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: separated debuginfo patch
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Philippe Elie <phil dot el at wanadoo dot fr>, Nick Clifton <nickc at redhat dot com>,graydon at redhat dot com, oprofile-list at sourceforge dot net,binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Fri, 18 Jul 2003 10:03:00 -0400
- Subject: Re: separated debuginfo patch
- References: <87wuf3s4q3.fsf@dub.venge.net> <3F02B1A5.5000102@wanadoo.fr> <87adbwpkhj.fsf@dub.venge.net> <3F03EB19.4090801@wanadoo.fr> <m3brwasjkh.fsf@redhat.com> <3F062EDF.4060801@wanadoo.fr> <3F17F93A.4030805@redhat.com>
On Fri, Jul 18, 2003 at 09:42:18AM -0400, Andrew Cagney wrote:
> Philippe,
> >
> >[trying to avoid crc'ing the separate debug file]
> >
> >I need to know how GDB guys want I deal with the gdb part, for now
> >gdb.diff just remove (#if 0) all duplicated code from bfd and use
> >bfd_follow_gnu_debuglink() to retrieve the debug info file. Is it
> >ok to remove this code or must I update the duplicated code according
> >to the change in bfd ?
>
> I just wonder if it should eventually be made more transparent?
> bfd_openr (file, FOLLOW_DEBUG_LINK).
> Doing things like:
> objdump --follow-debug-link
> would then become possible. Regardless, it makes sense to put the
> algorighm in BFD.
It should. I talked Graydon into trying this at the time he submitted
the BFD part - it turned out to be a world of trouble given BFDs
current data structure, and we bailed out.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer