This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- Comment #10 from jason at redhat dot com  2008-10-16 18:40 -------
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

mark at codesourcery dot com wrote:
> 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.

In which case we need to specify -femit-class-debug-always, yes.

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

I wouldn't expect it to make a big difference with heavily templated 
code, no.

It seems to me that you're arguing that -femit-class-debug-always should 
go back to being on by default; its only effect is to control this exact 
optimization.  But the documentation says

--
This option
should be used only with debuggers that are unable to handle the way GCC
normally emits debugging information for classes because using this
option will increase the size of debugging information by as much as a
factor of two.
--

Does anyone have some recent numbers?

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]