From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7922 invoked by alias); 11 Jun 2003 14:27:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7866 invoked from network); 11 Jun 2003 14:27:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 11 Jun 2003 14:27:21 -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 h5BERKH25173; Wed, 11 Jun 2003 10:27:20 -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 h5BERKI16054; Wed, 11 Jun 2003 10:27:20 -0400 Received: from localhost.localdomain.redhat.com (vpn50-23.rdu.redhat.com [172.16.50.23]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5BERBE26659; Wed, 11 Jun 2003 10:27:18 -0400 To: Jakub Jelinek Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: RFC: Support for separate debug info files References: <20030611134532.GW24872@sunsite.ms.mff.cuni.cz> From: Nick Clifton Date: Wed, 11 Jun 2003 14:27:00 -0000 In-Reply-To: <20030611134532.GW24872@sunsite.ms.mff.cuni.cz> (Jakub Jelinek's message of "Wed, 11 Jun 2003 15:45:32 +0200") 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-06/txt/msg00371.txt.bz2 Hi Jakub, >> This leads me to my main point. Do we need the ability to create >> stripped debuginfo files ? The original patch did this, but it >> turns out to be problematical since the debuginfo files need to >> contain dummy versions of the .text, .data, etc sections. Doing >> this, rather than just stripping them out, looked non-trivial, so I >> decided to skip it for this version. > > By stripped debuginfo files you mean what eu-strip -f creates, > right? Err, probably. I mean debuginfo files that work with GDB and which can provide the necessary information to allow the debugging of a stripped executable. I found that just collecting together the various .debug.* sections (and associated symbols) was not enough. The debuginfo also needs a full section table and program header table, with dummy entries for the stipped out sections. And producing this kind of file would be, IMHO, tricky. > which is how you install it, because suddenly you have to transfer > more bytes from the network in order to debug packages, and not > everybody has a fast pipe. But then not everyone wants to debug anything. And the number of people who are going to want to debug a big executable (eg openoffice) is probably very small. So by being able to ship a program as a small, quick to download package which only becomes big if the second, debuginfo package has to be downloaded, people will be encouraged to use it. Similarly for distributions, this change would allow a distribution to be shipped in a much smaller space, possibly on less CDs, and only a few people are going to want to download/buy the extra CDs containing the debugging info. Well that is my theory anyway... :-) Cheers Nick