From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29003 invoked by alias); 15 Oct 2008 22:52:26 -0000 Received: (qmail 27651 invoked by alias); 15 Oct 2008 22:51:03 -0000 Date: Wed, 15 Oct 2008 22:52:00 -0000 Message-ID: <20081015225103.27650.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mark at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01036.txt.bz2 ------- Comment #9 from mark at codesourcery dot com 2008-10-15 22:51 ------- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always jason at redhat dot com wrote: >> But, I think it's odd if I'm in the debugger, looking at code that says: >> >> return (X*)y; >> >> if I can't say "print (X*)y". >> >> If the type is coming from a library, we may not ever create objects of this >> type. > > If the Xes are created in the library, the library should have the debug > info we need. That assumes a friendly library distributor. :-) The library is provided to us in binary form and stripped, and if it does have debug info it might not have come from GCC. But, if it's declared in a header, we can still provide debug info. >> Finally, we use vast amounts of space in object files for debug info, since we >> emit the same debug info in multiple object files. Trying to optimize by not >> emitting debug info in this case doesn't seem likely to be a big win given our >> overall strategy. I don't have any data to support that claim, though. > > I'm not sure what overall strategy you mean. We try to avoid emitting > the same info in multiple places when possible: we try to treat the > debug info for classes as another vague linkage entity and put it with > the vtable. OK, my statement was overly strong. I was thinking particularly of C++ templates, where the vague linkage strategy makes for lots of copies, both in the object files, and, because we don't use COMDAT, in the final binaries. In that kind of C++ code, this optimization doesn't save a significant percentage of space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429