From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9252 invoked by alias); 15 Oct 2008 22:24:29 -0000 Received: (qmail 8414 invoked by alias); 15 Oct 2008 22:23:05 -0000 Date: Wed, 15 Oct 2008 22:24:00 -0000 Message-ID: <20081015222305.8413.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: "jason at redhat 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/msg01033.txt.bz2 ------- Comment #8 from jason at redhat dot com 2008-10-15 22:23 ------- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always mmitchel at gcc dot gnu dot org wrote: > /* Make sure we didn't eliminate casted types because we thought they were > unused. */ Yes, my point was that the reason we omit the debug info in this case is not that we think the type is unused, it's that even though we know it is used, we expect it to be emitted elsewhere. > 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. I can't imagine a use for a statement like that in a program that doesn't have a definition of the vtable for X. If no X has ever been created, then doing anything interesting with the X* will have undefined behavior, because it couldn't possibly point to an X. > 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. Unfortunately, it isn't yet possible to use linkonce for debug info because of GDB limitations, so our opportunities for optimization are limited. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429