This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Implicit DWARF relocs


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
.rela.debug_info
        .debug_str      1643281
        .debug_loc       363564
        .debug_ranges    163042
        .debug_line         305 
        .debug_abbrev       305
        others           769945
.rela.debug_macro
        .debug_str      4083259
        .debug_macro      68995
        .debug_line         305
.rela.debug_loc
        .text           2718726
        others           212556

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]