Re: [PATCH] Eliminate duplicate dwarf2 data

[Daniel Berlin <dberlin at redhat dot com>]

On Sun, 27 Aug 2000, Gary Funck wrote:

> 
> A few thoughts on proposed patch:
> 
> - As Jason noted, the use of a "compilation unit" to track definitions
>   within an include file, doesn't appear to follow the spirit of
>   the DWARF2 standard.  There may be other consumers of DWARF2, that
>   won't work well, or will be confused by this use of compilation unit.
>   The solution is that this optimization can be disabled with a swtich, I
>   suppose, but a standard-conforming implementation seems better in
>   general, and in the long run.
>

This is completely standard conforming   when it gets through the linker.
Didn't you read how i use dwarfdump and readelf to verify the info, in
addition to various other debuggers that read dwarrf2?
They read and handle it perfectly fine, because it is perfectly standard.
Also, the use of a compilation unit to track include files is exactly what
the dwarf2 standard had in mind.

> - dwarf2out.c is getting to be quite a beast, and the proposed patches
>   appear to impact quite a few areas.  If you do decide to go this
>   route, would a post-pass over the already generated (single)
>   compilation-unit DIE, breaking it out into separate sub-trees, do
>   a better job of localizing the optimizing code? 

Err, that's what break_out_includes,etc does.

 Perhaps the
>   optimization can be located into a separate source file, even,
>   like dwarf2opt.c, or some such.
> 
> - Even though the md5 checksum will be fairly air tight, I agree with
>   Andi K. that the design criteria "_should_ never happen", always offers
>   the possbility of "might happen", even if the odds are low.  Generally,
>   that sort of approach isn't recommended for system programs and
>   development tools.


Sorry, i object to this objection.
Given the constraints, i believe it's impossible for it to ever occur.
Please prove me wrong otherwise.
Please show how you could collide it, given the constraints i mentioned in
another message (that the file name must be exactly the same, as would the
number of dies.)

 > - If the objection to doing the work in the linker is
that it requires
>   elements of both the DWARF2 reader (in gdb), and the writer (in gcc),
>   wouldn't one approach be to develop a library that can be called from
>   gcc, gdb, and ld?
I don't have time.
There is one called libdwarf, by SGI, which is LGPL'd now, but we can't
use it.

>  This library might prove useful elsewhere, in the
>   future.  However, I think the type of writer that 'ld' would need
>   is different than currently in gcc.  GCC generates assembler source
>   code, and 'ld' works with sections, relocation values, and the like.
>   I suppose 'ld' could always generate assembler source, and then exec
>   the assembler, and read back the object file, but that seems a little
>   far-fetched.
> 
> That said, it would be nice to decrease the size of the debugging
> info., and the speed of loading that info., and it looks like this
> include optimization can offer a big win.  Do you have any statistics
> on how much space is saved, in a typical large executable, such as
> gcc, or the Linux kernel?

Neither are C++ apps, which really tax dwarf2, due to the tendency for
include files to have debug info.
However, a simple 6 line bs C++ file pulling in most of the STL, compiled
18 times, results in a 9 meg executable without the patch, and under a meg
with it.

 > 
> Recommendation: isolate the DWARF2 optimization into a separate pass
> over the compilation DIE, and place this code in a separate source file
> inside GCC.  
Just move the associated code from break_out_includes, etc into that
file. I already seperated this stuff out.

Before the patch, even compilation unit generation was inlined into a
routine it doesn't belong in.
Now it's in output_comp_unit.
I specifically tried to move things into routines, rather than inline them
into placse they don't belong, so you could seperate it into a different
file if you chose.

 >This should make the current dwarf2out.c
implementation
> (a little) easier to follow, and it should be easier to eliminate the
> gcc component of the DWARF2 optimization, in the future, when/if 'ld'
> does the optimization, which is (I think) the right place for collescing
> the DWARF2 debugging info.
> 
It would be very difficult to implement it in LD, as LD stands today.
I wasted a month trying.
--Dan
>