From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30760 invoked by alias); 18 Jul 2003 14:41:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30475 invoked from network); 18 Jul 2003 14:41:06 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 18 Jul 2003 14:41:06 -0000 Received: from dub.venge.net (sebastian-int.corp.redhat.com [172.16.52.221]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h6IEf4K11241; Fri, 18 Jul 2003 10:41:05 -0400 To: Daniel Jacobowitz Cc: Andrew Cagney , Philippe Elie , Nick Clifton , oprofile-list@sourceforge.net, binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: separated debuginfo patch References: <87wuf3s4q3.fsf@dub.venge.net> <3F02B1A5.5000102@wanadoo.fr> <87adbwpkhj.fsf@dub.venge.net> <3F03EB19.4090801@wanadoo.fr> <3F062EDF.4060801@wanadoo.fr> <3F17F93A.4030805@redhat.com> <20030718140300.GA15751@nevyn.them.org> From: graydon hoare Date: Fri, 18 Jul 2003 14:41:00 -0000 In-Reply-To: <20030718140300.GA15751@nevyn.them.org> Message-ID: <87vftzkidi.fsf@dub.venge.net> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00241.txt.bz2 Daniel Jacobowitz writes: > 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. yeah, we gave up on "transparent" access in bfd_openr due to the ugliness of merging symbols from separate bfds; nonetheless the requisite (distinct) debuglink-following function was added upstream. http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/opncls.c.diff?r1=1.13&r2=1.14&cvsroot=src&f=h -graydon