Re: sh-elf: the substraction of two symbols

[Toshi Morita <tm2 at best dot com>]

> 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.

> 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.

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.

> > Also the Hitachi SHC toolchain uses REL relocations as well
> > so it would increase compatibility with other toolchains.
> 
> Does that toolchain do the same sorts of relaxation?

No. They perform relaxation at compile-time which is not as 
comprehensive.

> Ian

Toshi