Re: Linking libstdc++ with gcc-3.0.2 prerelease fails on IA64

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Oct 15, 2001 at 08:23:13PM -0700, H . J . Lu wrote:
> > Hmm, I wondered whether I was doing the right thing leaving the relocation
> > type as it was.  Why not just do
> > 
> > rel->r_info = 0;
> > 
> > After all, we rely on R_*_NONE being zero in other places.  In fact, it's
> > probably safest to zero the entire reloc, like this:
> > 
> 
> I believe we should look up BFD_RELOC_NONE and set r_info only with
> ELF_R_INFO. But I don't have a strong opinion on that. I only want to
> stabilize the linker.

A lot of code would break if R_*_NONE was not zero (binutils, libelf,
prelink), so I'd find memset(, 0, ) more readable (and ensuring that it
doesn't have non-zero addend, or offset).

Actually, I think binutils should go even further:
Does any ELF backend rely on R_*_NONE relocs being present in some reloc
section? If not, IMHO before writing the reloc sections down, bfd should
move the NONE relocs to the very end (including after
.rel{,a}.{plt,IA_64.pltoff}) and adjust relevant dynamic tags, so that
although it still consumers memory, dynamic linker doesn't have to read them
all at runtime and fill caches with it (e.g. I saw 2117 R_*_NONE
relocs in libc.so.6 on PowerPC, which means almost 25KB of memory read just
because bfd did a poor job).
Of course, bfd should primarily try to discover NONE relocs before sizing
sections if possible, so that they don't occupy space in binaries either.

	Jakub