Re: dwarf2out multiple CU patch

[Daniel Berlin <dberlin at redhat dot com>]

> 
>  > They were necessary because unless you changed something today, we were
>  > using ref_addr to refer to things that other DIE's might also refer to
>  > (and thus, had a symbol), even within the same CU.
>  > In other words, if something needed a ref_addr from somewhere, we used
>  > ref_addr from everywhere, even if it was in the same CU.
> 
> That shouldn't happen; the code just checks for an offset of 0, which
> should always give the right answer, and is cheaper than looking up the
> parent CU.  I just checked, and the current code handles the DIE for 'int'
> properly, at least; references from other CUs use ref_addr, and refs from
> the same CU don't.

I could swear it wasn't working properly before i added that code. Did one
of your other fixes from today make this start working?
I'm quite sure that's the reason i did it.

> 
>  > Also, the ChangeLog's should probably note that i changed the various code
>  > you wrote, and some you didn't, to stop assuming that if the parent wasn't
>  > current_comp_unit or whatever, it wasn't the direct child of a compile
>  > unit. Instead i made it check if the parent had a DW_TAG_compile_unit.
> 
> Actually, I left that change out as well; checking against comp_unit_die is
> fine until after we call break_out_includes.

FOr some reason, this doesn't seem like a good idea. If some other
processing gets moved around to after we break out the includes, it'll
unexpectedly break and nobody will know why.

> 
>  > FYI: I'm sure you know this, but the last bit of duplicated info is coming
>  > from templates having their debug info put into the place they get
>  > instantiated.
> 
> Yup.  Do you think it would make things smaller to put instantiation DIEs
> in the header CUs?  I would expect that to reduce sharing, but perhaps it
> would be an overall win.

It's hard to say.

> 
> What are you using to measure the savings?
BeOS C++ applications, which use tons of declarations, headers, etc.
I have a development environment i've been working on with some
ex-inprisers.
In addition to the BeOS standard library headers, we have our own
libraries, and since the whole thing is plugin based, and the pieces
communicate with each other through messages, we have tons of headers that
get included int he same place.
Without the patch, it's about 100 meg with debug info, with the patch,
it's about 20 meg.
I haven't recompiled two pieces, so that number will probably be even
lower.
It's a huge win, however.

Once i unpack at schooll,, i'll compile mozilla with dwarf2 with and
without the patch (My laptop doesn't have the diskspace), and report some
stabs.

However, on average, i'm seeing 7 fold reductions in the amount of debug
info.

Of course, the more headers shared between files, the better the patch
makes the situation, and the worse it is without the patch, so it's hard
to say.
--Dan
> 
> Jason
>