From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30472 invoked by alias); 12 Jul 2005 01:18:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30457 invoked by uid 22791); 12 Jul 2005 01:18:25 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 12 Jul 2005 01:18:25 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1Ds9Pi-0005nw-TT; Mon, 11 Jul 2005 21:18:22 -0400 Date: Tue, 12 Jul 2005 01:18:00 -0000 From: Daniel Jacobowitz To: Jason Molenda Cc: Devang Patel , GCC Development Subject: Re: Reducing debug info for C++ ctors/dtors Message-ID: <20050712011822.GA22286@nevyn.them.org> Mail-Followup-To: Jason Molenda , Devang Patel , GCC Development References: <20050712005636.GA21559@nevyn.them.org> <20050711181158.A10767@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050711181158.A10767@molenda.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00476.txt.bz2 On Mon, Jul 11, 2005 at 06:11:58PM -0700, Jason Molenda wrote: > Yeah, Devang didn't present what we're doing here on the debug side > too well. We're giving up a bit of information from within gdb -- > it won't know what constructors and destructors a class has defined > -- for a large savings in debug info (this can be over 20% of an > application's debug info when lots of templates are in heavy use). > > Because the FUN stabs are still present, gdb knows about the > constructors; it can step into them, it can set breakpoints on them. > > For most developers, this isn't a worthwhile tradeoff, but for a > certain class of appliations the stabs debug info is enormous and > this helps to ameloriate that by giving up a small bit of gdb > functionality. This won't be enabled by default even within Apple, > but it is a useful option to have available. Thanks for the explanation. That makes more sense. Personally, if you're going to do this, I don't see why you're keeping debug info for methods; either ditch all artificial methods (including defaulted constructors but not manually specified constructors), or ditch all methods. -- Daniel Jacobowitz CodeSourcery, LLC