RFC: Implicit DWARF relocs
Wed Apr 25 21:59:00 GMT 2012
On Wed, Apr 25, 2012 at 12:02:10PM -0700, Cary Coutant wrote:
> > I've looked at the DWARF Fission proposal and to me it looks that lots of
> > efforts is spent on decreasing the size of the debug info related relocations
> > on ET_REL objects, often (at least in my understanding) at the cost of
> > increasing the debug info (but by smaller amount than the saving on the size
> > of relocations).
> Let's break this down into separate pieces:
With this I'm not trying to replace Fission in any way, I've been just
thinking about decreasing disk space usage for debug info usage where the
most important thing is the final debug info size of linked objects, but
it doesn't hurt if the ET_REL size/*.a of them decreases.
For the size of debug info in commonly linked shared libraries/binaries in
the distributions and from work on dwz I think a single pass over selected
debug sections, just parsing the forms isn't that expensive, the sections
will be largely paged in during relocation processing anyway.
On my latest gcc build, looking at libbackend.a, there is ~ 70MB total of
.rela.debug_info sections, ~ 70MB total of .rela.debug_loc sections and
~ 100MB total of .rela.debug_macro sections. By adding implicit relocations
there, the first 5 kinds of .rela.debug_info, or the first kind of
.rela.debug_macro, or big part of the first kind of .text relocs in
.debug_loc could be saved, so libbackend.a could shrink from ~ 750MB by
guess 200MB or slightly more than that.
Except for .debug_loc DW_FORM_strp is really the most important one,
but by adding an indirection table I'm afraid debug info will grow for the
final executable unnecessarily. From looking at several larger *.o files,
usually most of the DW_FORM_strp references are present just once, so even
if you use uleb128 as references to the indirect table, it will for large
CUs be mostly 6 bytes for string reference instead of just 4.
number of relocations
More information about the Binutils