[LLVMbugs] [Bug 20741] default debug level does not play well with libstdc++

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Aug 25 10:58:52 PDT 2014


David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from David Blaikie <dblaikie at gmail.com> ---
(In reply to comment #3)
> In my opinion it is better to make the setting that provides the expected
> functionality for all users the default and let users concerned about file
> size hunt the manpage for an option to reduce it rather than the other way
> round. 

FWIW, GCC has the same default (and the same/similar optimizations (the
std::string one is different - but try hello world in GCC and observe that GCC
produces only a declaration for std::fstream):

  DW_TAG_class_type [30] *
    DW_AT_name [DW_FORM_strp]     ( .debug_str[0x00000283] =
"basic_ostream<char, std::char_traits<char> >")
    DW_AT_declaration [DW_FORM_flag_present]      (true)

More than just the same default, -g1, -g2, -g3 have no affect on this. The only
way to produce the definition of basic_ostream<char..> from hello world is:

Instead of emitting debugging information for a C++ class in only one object
file, emit it in all object files using the class. 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 increases the size
of debugging information by as much as a factor of two. 


Though just because they did it doesn't /necessarily/ mean we should. But
there's no argument from compatibility (except maybe to provide a flag alias)
with -gN flags.

> -fno-standalone-debug really only works for a project when every
> single C++ library is also compiled with debug info. On platforms where this
> statement is likely to be false (3rd-party libraries, etc), the default
> should be -fstandalone-debug.

3rd party libraries don't necessarily make this statement false - they can/do
provide debug builds of those libraries.

If you don't have debug builds of your libraries it's not hard to get into a
situation where you don't have enough type information (pimpls would be a
common example - the headers just won't have the type information you might
want to inspect the state of the objects you're interacting with).

But, yes, -fstandalone-debug should get you to a point where any expression you
wrote in the source, you can also write successfully in your debugger
expression evaluator, give or take a few things.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140825/3213c706/attachment.html>

More information about the llvm-bugs mailing list