Re: Debug formats on Linux

[Daniel Berlin <dberlin at redhat dot com>]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Fri, 27 Oct 2000, Mark Mitchell wrote:
> 
> > I suspect that every new GCC platform will use DWARF2.  (I think that
> > IA64-Linux uses it.)
> >
> > Why we can't switch on IA32-Linux is still somewhat beyond me, and I
> > still find the documentation as I did years ago.
> 
> The following patch does the minimal conservative solution of making
> the change on i?86-pc-linux-gnu only - it could probably be made in
> the toplevel linux.h instead.
> 
> It isn't yet ready to commit, because of the following test
> regressions on i686-pc-linux-gnu (though, it removes the two failures
> for g++.ext/instantiate1.C):
> 
> FAIL: gcc.c-torture/unsorted/loop386.c,  -O3 -g
> (ICE at dwarf2out.2:8366 (add_abstract_origin_attribute))
> 
> FAIL: g77.f-torture/compile/20000511-2.f,  -O3 -g
> FAIL: g77.f-torture/compile/20000629-1.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-3.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-4.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-7.f,  -O3 -g
> FAIL: g77.f-torture/execute/19981119-0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto1.f compilation,  -O3 -g
> (all ICE at dwarf2out.c:8114 (add_bound_info))
> 
> These can be tested without the patch by compiling the individual
> testcases with -gdwarf-2 -O3; perhaps someone understanding Fortran
> and g77 could look at why those Fortran cases crash and whether the
> problem is with the Fortran front end or in the DWARF2 support.
> [NOTE: -gdwarf-2 not -gdwarf2, since -gdwarf2 is DWARF1, as discussed
> long ago.]
> 
> (The change does increase executable sizes somewhat - by about 40% -
> but of course this only affects unstripped executables compiled with
> debugging.  Where the disk space is a problem a user can always use
> -gstabs or -g1 and trade disk space against the reduced expressivity
> of the debug information and possible difficulties debugging in the
> presence of some optimisations.  In addition, -feliminate-dwarf2-dups
> reduces the overhead to about 18%.)


Yeah, you really need to use C++ programs to see a much bigger gain
from eliminate-dwarf2-dups.

Also, if you look at the overhead, most of it is actually because of
the labels we use in eliminating the dups. 
If you do everything possible to cut down the number of labels in the
assembly file, you'll get much smaller dwarf2 files.

For a test, change dwarf2out.c to never emit labels for
inter-die-references (which of course, defeats the purpose, and makes
it useless, but this is just for test purposes), and watch how much
smaller your dwarf2 executables get.



--Dan