From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21897 invoked by alias); 11 Jun 2003 13:43:32 -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 21853 invoked from network); 11 Jun 2003 13:43:32 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 11 Jun 2003 13:43:32 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Q5tf-00056F-00; Wed, 11 Jun 2003 08:44:15 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Q5su-0003RA-00; Wed, 11 Jun 2003 09:43:28 -0400 Date: Wed, 11 Jun 2003 13:43:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Nick Clifton , gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: RFC: Support for separate debug info files Message-ID: <20030611134326.GA13158@nevyn.them.org> Mail-Followup-To: Jim Blandy , Nick Clifton , gdb-patches@sources.redhat.com, binutils@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00366.txt.bz2 On Wed, Jun 11, 2003 at 08:36:29AM -0500, Jim Blandy wrote: > > Nick Clifton writes: > > 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. > > > > My theory is that the only benefit gained by being able to ship a > > stripped debuginfo file as opposed to an unstripped one is that it > > reduces the shipping size, making a distribution smaller. I am > > assuming that hard disk space is not really an issue, just the size > > of the shipped binaries. > > I think the idea is to omit the debug info files altogether from the > distribution. It'll make the debug info packages take longer to > download, but it's not a show-stopper, I think. For me it probably is a show-stopper - the issue is not download time or disk space, but CD size. Duplicating all the binaries we want to provide debug info for would probably push us over the edge. It could be done separately though! This will at least let us test it... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer