Re: mips unordered symbol table and relocations

[Ian Lance Taylor <ian at airs dot com>]

Nathan Sidwell <nathan@codesourcery.com> writes:

> A windriver customer encounted a linker crash with a library archive produced
> by an old toolchain. The symbol table is unoreded, with local and global
> symbols intermixed. Some relocations were against symbols with no entry
> in the (global) hash table, and these caused problems. objdump shows these
> as relocations agains *ABS*. It may be possible that I've misunderstood these
> *ABS* relocs, and the object file is infact corrupt. However, the attached
> patch allows linkage to proceed. ok?

The code should already handle this case, by testing whether there is
an entry in the sections table.  Your patch appears to supplement each
test of the sections table to also test the linker's global symbol
table.  But every symbol should have an entry in either the sections
table or in the global symbol table.  The extra test should not be
necessary.

What does the object file in question actually look like?  What is the
symbol index which appears in the relocation entry?  Perhaps readelf
can help here.

It's possible that the object file has relocations against symbol 0,
and that is not being handled correctly.  I think it would be cleaner
to handle that correctly, perhaps by simply setting finfo->sections[0]
to bfd_abs_section_ptr near the start of elf_link_input_bfd().

Ian