From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9738 invoked by alias); 4 Jul 2003 10:04:55 -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 9680 invoked from network); 4 Jul 2003 10:04:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 4 Jul 2003 10:04:49 -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 h64A4nH24438; Fri, 4 Jul 2003 06:04:49 -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 h64A4nI22147; Fri, 4 Jul 2003 06:04:49 -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 h64A4di21565; Fri, 4 Jul 2003 06:04:46 -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> From: Nick Clifton Date: Fri, 04 Jul 2003 10:04:00 -0000 In-Reply-To: <3F03EB19.4090801@wanadoo.fr> (Philippe Elie's message of "Thu, 03 Jul 2003 08:36:41 +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/msg00076.txt.bz2 Hi Philippe, > cc'ing binutils list [And adding gdb since this affects how debuginfo files are processed]. > hi, we was discussing about the separate debug info files. > I've some doubt than crc is the right way to check for debug > file match. > Changed my mind, now I think a timestamp is better. > This sort of problem is generally solved by a timestamp > (64 bits) not a crc, both file contain the same timestamp and > the timestamp must be equal, imho crc is usefull to check file > corruption not file matching Although by having a crc you can do both at the same time. > crc *can*(1) be here if someone want to check if the debug file > is corrupted but this must be a client decision to check the > crc not a bfd one. With the current scheme I'm unusure than an > operport -l will work enough well since we can get easily a few > GB of debug info leading to an opreport slower by a few magnitude > order. It can be usefull for gdb itself, what will occur if I try > to get a bt for OpenOffice and it's 1.2 GB of debug info in separate > debug file ? > > doing it in this way seems feasible: > > objcopy --add-gnu-link will add a timestamp section in both > debug file and binary which can be used to check file match > by bfd lib. > > BFD maintainers is this scheme sensible? The problem binutils has is that the debuginfo file and .gnu-debuginfo section in the stripped file are created by two different steps (1). Thus adding the same timestamp to both files is tricky and would require that the debuginfo file be first created with a blank timestamp section and then later, when the .gnu-debuginfo section is added, the timestamp is initialised. The other problem with timestamps is that it means that bootstrap sequences that involve the creation of debuginfo file will no longer work. ie the debuginfo files and stripped executables from two different bootstrap stages will no longer compare as identical because of the timestamps. This problem could be avoided by using a unique-binary-identifier that is specified on the command line, rather than a timestamp that is generated by the objcopy/strip program. ie objcopy could have a new switch such as: --set-debuglink-timestamp= If this switch is not specified when --add-gnu-debuglink is used, then a timestamp is added, otherwise is added. Generating a non-trivial value for however might prove difficult... Still, I am not totally opposed to the idea, and if the gdb guys agree I would be happy to consider a patch adding these features. (I am a bit swamped at the moment, so I do not have time to create the patch myself). It should not be too hard to do. 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). Possibilities for the new section in the debuginfo file include: .gnu_debuglink (ie reuse the section name that is found in the stripped executable. The version in the debuginfo file could be exactly the same format, or it could be a shortened version with only the timestamp and not the filename or crc). .gnu_debuglink_timestamp (a bit wordy, but self documenting) .note.gnu.debuglink.timestamp (even longer, but who's counting ? :-) Cheers Nick (1) This was a deliberate choice on my part since the strip and objcopy tools historically only ever have one output file. I could have changed their internals to handle multiple outputs, but this was more work than I wanted to do, and I believe in keeping things simple unless forced to add complications.