[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

["mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

------- 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