Re: linker debug info editing

[Daniel Berlin <dberlin at dberlin dot org>]

> I spent a large amount of time when we were implementing
> -feliminate-dwarf2-dups measuring the cost of various schemes for
> deciding what to try to split and what not.

Oh, i forgot the other half of problems.

If you don't do something like split every die, then you get into things
where you have to name the linkonce sections by the content (using md5
hashes or something), so that you'd don't accidently eliminate one set
of dies that really isn't an exact duplicate of some other.

Once you do this you get hit with ordering issues if the include files
in something else are in a slightly different order, and this causes the
md5's to be different.

*or* you hit the problem that you may not split exactly the same (due to
ordering, more dies, etc), and thus, the dies in one split CU may be
different than another, and thus, will not be commoned (because they
will have different linkonce section names from the content hash)

If you do something obvious like split every type/subprogram die into
it's own section, and linkonce those, the cost in .o files is enormous.

Then, for each type DIE, you have:

12 bytes for a debug_info header
~10-20 bytes of extra overhead from using dw_form_refaddr references
(assuming it is referenced ~3-5 times)
30 bytes for the new section name (.debug_info.linkonce.<16 byte md5>)
10+ bytes (i forget the number) for the extra section table entry you've
added
10+ bytes for the extra symbol you need to reference the thing
everywhere else

It ends up being about 100 bytes per die you put into it's own CU

If you have a C++ app, and 5000 types, you've just wasted 500k.
I had tried this scheme once, and it usually doubled (or more) the size
of the .o files.

IOW, it's always a better idea to eliminate in the linker if possible,
which has *none* of these issues.

It's hard work, but straightforward there if you have all the info you
need.