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

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

[Ruppert]

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

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

[Ian Lance Taylor]

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.

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.

Ian

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

[Ruppert]

Hello,

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

I put together a minimal example (a source file including two header files
with a struct definition each) and was surprised to see that all this seems
to work when compiled as C, but not when compiled as C++:

When compiled with gcc-4.4.4 as C code, I get the following two sections
in the resulting object:
     .gnu.linkonce.wi.bar.h.60f9683b 
     .gnu.linkonce.wi.foo.h.22b1f5d9
 
I think this is as it should be: the compiler creates separate "compilation
unit" sections for the contributions from each header file, and the linker 
emits only one of possibly many identical sections from the header files
into the final executable (so is my naive understanding of the mechanism...)

When compiled as C++ code (by specifying -x c++), I get only one such section
which is named after the source file, not after the header files:
     .gnu.linkonce.wi.bar.c.b403f86f
This does, I think, defeat the whole mechanism: the linker will simply add 
the contents of this section to .debug_info in the executable, and this
will not result in any savings.

From this I conclude that there seems to be something wrong with 
-feliminate-dwarf2-dups when used with C++ (unless I am seriously misunderstanding
this mechanism or I have somehow misconfigured gcc).

I observe this with gcc-4.4.4 built for Solaris10/x86 (configured to use
the GNU linker).

Has anybody tried this option recently with gcc-4.4.x and C++? The Sun-built gcc
(which is version 3.4.3) seems not to have this problem.

The (trivial) setup is as follows: 

------ source file bar.c: --------
#include "foo.h"
#include "bar.h"

struct Foo myfoo;
struct Bar mybar;
----------------------------------

------ header file foo.h: --------
struct Foo {
    double d_foo;
    int i_foo;
};
----------------------------------

------ header file bar.h: --------
struct Bar {
    double d_bar;
    int i_bar;
    char c_bar;
};
----------------------------------

The compilation commands:
  as C code:
     .../gcc -gdwarf-2 -O2 -feliminate-dwarf2-dups -c bar.c 
  as C++ code:
     .../gcc -x c++ -gdwarf-2 -O2 -feliminate-dwarf2-dups -c bar.c

I obtained the section names by using
     elfdump -c bar.o | grep linkonce
     

Any help or insight into this would be very much appreciated. 

Regards
Dieter Ruppert