>
>Ruppert <dieter_ruppert@xxxxxxxxxxx> writes:
>
>> I am trying to reduce the size of debug information for a large C++ project
>> and tried -feliminate-dwarf2-dups. This did not work as expected, I got even a
>> slight increase in .debug_info (instead of some decrease).
>
>You're right. -feliminate-dwarf2-dups does not work with C++. This
>seems to be because the C++ frontend does not generate the debug
>information for typedefs as it is reading the source files. It only
>generates it after all the sources files have been read, and it does not
>associate it with the appropriate header file. This is probably a bug,
>though it may not be an easy one to fix.
I debugged this a bit, and found that the C++ frontend does not associate
any debug information at all with the "compilation units" from header files.
Conceptually, the DIE hierarchy created from my trivial example looks as
follows with -feliminate-dwarf2-dups:
when compiled as C:
compile_unit(bar.c)
bincl(bar.c)
bincl(foo.h)
structure_type(Foo)
members of Foo
eincl
bincl(bar.h)
structure_type(Bar)
members of Bar
eincl
eincl
variable(myfoo)
variable(mybar)
when compiled as C++:
compile_unit(bar.c)
bincl(bar.c)
bincl(foo.h)
eincl
bincl(bar.h)
eincl
structure_type(Foo)
members of Foo
structure_type(Bar)
members of Bar
eincl
variable(myfoo)
variable(mybar)
It is obvious that in the C++ case the "compilation units" for the
header files, which are created from the bincl/eincl sequence, remain
empty and are therefore discarded. The structure_type definitions, which
in the C case are attributed to the header files, are in the C++ case
created in the context of the source file bar.c, hence the section
named after the source file in the object.
This seems to confirm that the C++ frontend creates all debug information
only after all header files have been read, and so this bincl/eincl context
is lost.
I understand that this is probably very hard to change.
>
>Fortunately in mainline gcc, when using -gdwarf=4, there is a better
>approach to reducing the size of C++ debug info, which permits much more
>duplicate information to be eliminated at link time. This will be in
>gcc 4.6.
Thanks for the clarification, anyway. For the time being, I have to cope with
an executable size of about 200 MB, 180 MB of which is debug info...
Regards
Dieter Ruppert
