This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: sh-elf: the substraction of two symbols
- To: ian at zembu dot com (Ian Lance Taylor)
- Subject: Re: sh-elf: the substraction of two symbols
- From: Toshi Morita <tm2 at best dot com>
- Date: Fri, 12 Jan 2001 18:43:00 -0800 (PST)
- Cc: binutils at sources dot redhat 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