From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31438 invoked by alias); 2 Oct 2009 09:45:01 -0000 Received: (qmail 31427 invoked by uid 22791); 2 Oct 2009 09:45:00 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Oct 2009 09:44:55 +0000 Received: from relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id CDB1D74609; Fri, 2 Oct 2009 11:44:53 +0200 (CEST) Date: Fri, 02 Oct 2009 09:45:00 -0000 From: Richard Guenther To: Joe Buck Cc: Andi Kleen , "gcc@gcc.gnu.org" Subject: Re: Prague GCC folks meeting summary report In-Reply-To: <20091002002057.GC13104@synopsys.com> Message-ID: References: <87d456u0l1.fsf@basil.nowhere.org> <20091002002057.GC13104@synopsys.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00034.txt.bz2 On Thu, 1 Oct 2009, Joe Buck wrote: > On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote: > > Richard Guenther writes: > > > > > > The wish for more granular and thus smaller debug information (things like > > > -gfunction-arguments which would properly show parameter values > > > for backtraces) was brought up. We agree that this should be addressed at a > > > tools level, like in strip, not in the compiler. > > > > Is that really the right level? In my experience (very roughly) -g can turn gcc from > > CPU bound to IO bound (especially considering distributed compiling appraches), > > and dropping unnecessary information in external tools would make the IO penalty even > > worse. > > Certainly life can suck when building large C++ apps with -g in an NFS > environment. Assuming we can generate tons of stuff and strip it later > might not be best. The agreement was based on the fact that 1) full debuginfo is necessary anyway (for -debuginfo packages) 2) we don't want to build a package multiple times just to get different levels of retained debug information. So the way it will work is that -debuginfo package generation will strip all but the pieces that should be retained in the binary. To make the above work first the external tools have to add the capabilities, just implementing it in GCC doesn't work for us. Richard.