Re: -feliminate-dwarf2-dups not working for C++ ?

[Ruppert <dieter_ruppert at siemens dot com>]

>
>Ruppert <dieter_ruppert@siemens.com> 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