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

[jason at redhat dot com]

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