From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16027 invoked by alias); 4 Jul 2003 23:38:31 -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 16013 invoked from network); 4 Jul 2003 23:38:30 -0000 Received: from unknown (HELO mwinf0103.wanadoo.fr) (193.252.22.30) by sources.redhat.com with SMTP; 4 Jul 2003 23:38:30 -0000 Received: from wanadoo.fr (AToulouse-206-1-3-24.w81-50.abo.wanadoo.fr [81.50.192.24]) by mwinf0103.wanadoo.fr (SMTP Server) with ESMTP id 55C971BFFF87; Sat, 5 Jul 2003 01:38:29 +0200 (CEST) Message-ID: <3F062EDF.4060801@wanadoo.fr> Date: Fri, 04 Jul 2003 23:38:00 -0000 From: Philippe Elie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Clifton 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00078.txt.bz2 Nick Clifton wrote: > Hi 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 ? > 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. I avoided it by forcing user to specify the timestamp in both step > > 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... I like it, such number is packager responsiblility, for gnu based system `date +%s` should be sufficient. I changed slightly it, number is not optionnal and must be provided by caller, is it a real problem ? > 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 disambiguite 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. > > 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) I tried to re-use exactly the same format but putting a valid filename in the .gnu_debuglink in debug info file conduct gdb into an infinite loop so on I preferred to play safe and use a separate section. The patch is a RFC rather than a submission, it needs some cleanup, updating bfd documentation etc. btw bfd documentation gives two alternative to use this feature but the first doesn't works with or w/o the attached patch: @item Run @code{objcopy --strip-debug foo} to create a stripped executable. @item Run @code{objcopy --add-gnu-debuglink=foo.dbg foo} to add a link to the debugging info into the stripped executable. gdb doesn't like file produced in this way and gdb document only the second way which works @item Copy @code{foo} to @code{foo.full} @item Run @code{objcopy --strip-debug foo} @item Run @code{objcopy --add-gnu-debuglink=foo.full foo} The patch is tested with gdb code with and w/o gdeb.diff applied, it works transparentely for gdb except obviously the old code always does the crc. patch can be tested through this two ways: gcc -g -O2 test.cpp cp a.out a.out.dbg strip --strip-unneeded a.out objcopy --set-debuglink-timestamp=12 a.out.dbg objcopy --set-debuglink-timestamp=12 --add-gnu-debuglink=a.out.dbg a.out gcc -g -O2 test.cpp cp a.out a.out.dbg strip --strip-unneeded a.out objcopy --add-gnu-debuglink=a.out.dbg a.out the first is now the preferred way. I don't like at all than gdb need the full file it makes separate debug info less usefull, can a GDB wizard gives some clues if it's feasible to use the file stripped from it's code/data section and if it'll be hard to implement ? regards, Philippe Elie