From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16562 invoked by alias); 11 Jul 2003 16:01:43 -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 16332 invoked from network); 11 Jul 2003 16:01:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Jul 2003 16:01:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6BG1cH15446; Fri, 11 Jul 2003 12:01:38 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6BG1cI03094; Fri, 11 Jul 2003 12:01:38 -0400 Received: from localhost.localdomain.redhat.com (vpn50-25.rdu.redhat.com [172.16.50.25]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6BG0mb01557; Fri, 11 Jul 2003 12:01:17 -0400 To: Philippe Elie Cc: graydon@redhat.com, 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> <3F062F6C.7050106@wanadoo.fr> From: Nick Clifton Date: Fri, 11 Jul 2003 16:01:00 -0000 In-Reply-To: <3F062F6C.7050106@wanadoo.fr> (Philippe Elie's message of "Sat, 05 Jul 2003 01:52:44 +0000") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00151.txt.bz2 Hi Philippe, Sorry for the long delay in replying - I have been very busy over the last few weeks. > 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 ? Well this is up to the gdb maintainers to decide, but it certainly seems like a good idea to avoid the code duplication. > > We just need to agree on the format and name of the timestamp > > section in the debuginfo file, and how to distinguish old > > .gnu-debuglink sections (only containing a crc) from new ones > > (containing a crc and a timestamp). > > I disambiguate the two case by looking the section size. See > bfd.diff, it's a bit ugly but I don't see how I can deal cleanly > with this problem. Actually I rather like this solution. Adding the timestamp as an extra field at the end of the .gnu-debuglink section seems rather elegant and it eliminates the need for a new section. Some comments on the patch: > + #define GNU_DEBUGLINK_TIMESTAMP ".gnu_debuglink_timestamp" This is not needed, since the timestamp is going to be held in the .gnu-debuglink section. > INTERNAL_FUNCTION > + bfd_get_debug_timestamp_info > + > + SYNOPSIS > + bfd_boolean bfd_get_debug_timestamp_info > + (bfd *abfd, unsigned long *timestamp); > + > + DESCRIPTION > + fetch the timestamp for any separate debuginfo associated with > + @var{abfd}. Similarly this function should extract the timestamp from the .gnu-debuglink section. > + printf("try %s %ld\n", name, timestamp); I assume that this is left over debugging ? > ! debuglink_size += 8; We ought to add a comment explaining why the value 8 is used here. Overall though I like the patch and the solution. If we can get the GDB maintainers to agree (or at least not object to) adding the extra field at the end of the .gnu-debuglink section then I would be happy to review a final version of the patch. (Note - you will need a FSF copyright assignment as well...) Cheers Nick