This is the mail archive of the binutils@sources.redhat.com 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]

Re: sh-elf: the substraction of two symbols


Toshi Morita <tm2@best.com> writes:

> > Toshi Morita <tm2@best.com> writes:
> > 
> > > As a major user of the sh-elf toolchain, we'd (Sega) actually prefer it 
> > > to use the REL relocation type instead of RELA. 
> > > 
> > > I have received numerous complaints that the relocation info is too
> > > large due to the usage of the RELA relocation type.
> > 
> > I couldn't do that and also do the fancy relaxation.  There just isn't
> > enough room to store the required information.
> > 
> > Well, I suppose I could have introduced some extra sections or
> > something, but relocations are a reasonable place to store this sort
> > of information.
> 
> Might have been better if the info was in a separate section.

Patches for this would probably be accepted.

Your comments are interesting, though.  It's normally easier to
implement using RELA relocations.  REL relocations make it difficult
to implement some desirable features on processors which build
addresses using more than one instruction.  This is not normally true
on the SH, as I recall, since it normally loads addresses directly
from memory.

> > Why do people care about the size of the relocation info, anyhow?  It
> > should only matter if they are doing some sort of dynamic loading of
> > relocatable files.  In that case, they should do something different,
> > like the MIPS ECOFF embedded-relocs hack.
> 
> We care about the size of the relocation info because:
> 
> 1) GCC spits out a huge amount of debug info for a project.
>    When generating an ELF file with 2 megabytes of machine code,
>    it's fairly typical to emit over 40 megabytes of DWARF debug
>    information.

There is a lot of work which could be done in the linker to eliminate
duplicate DWARF debugging information.  This would speed up link times
and produce smaller output files.

> 2) As you can guess from the previous statistic, over 99% of the
>    relocation info emitted is for the .debug section.
> 
>    For one of our projects, 99.7% of the relocations emitted
>    were for the .debug section.
> 
> These two factors contribute to extremely slow link times for us,
> on the order of 2+ minutes for some projects.

If you don't eliminate duplicate DWARF debugging information, then
even when switching from RELA to REL, the linker still has to actually
process all of those relocations.  Where is the linker spending most
of its time?  In reading the input files, or in processing?

Switching from RELA to REL would save 4 bytes per relocation.  Given
your numbers, I can optimistically imagine that this would save 10M in
input file space.  Saving 10M of reads when doing 42M of writes is not
insignificant, but it's not going to cut your link time in half.

I took a look at some DWARF 1 debugging information.  It has a lot of
relocs which are really not necessary--absolute addresses which could
easily be done as relative addresses which do not require relocations.
Improving that would save more time by eliminating many of the
relocations altogether--more than half, anyhow.  This work was done
for stabs, for example, by using file relative N_SO stabs rather than
absolute ones.

What do you see when you profile the linker?  Where is it spending
most of its time?  Unless you have evidence that switching RELA to REL
would help significantly, I would be inclined to try other approaches
first.

Ian

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