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