MIPS ELF ld -Ur fails

[Earl Chew]

"H . J . Lu" wrote:
> I looked at the code. The problem is in elf_bfd_final_link,
> elf_link_size_reloc_section is called before
> bfd_section_reloc_link_order can update
> elf_section_data(o)->rel_count.

Did you consider my patch?

Does it solve the underlying problem, or just paper over the bug?

> How should we fix it?

Regarding the nature of the problem, as I understand it, with
things the way they stand, elf_section_reloc_link_order() cannot
be called before elf_link_size_reloc_section() since the former
assumes relocation array space has been allocated by the latter.

In its current incarnation, elf_section_reloc_link_order()
not only updates elf_section_data(o)->rel_count, it also
modifies the relocation information.

This means that elf_link_size_reloc_section() must be called
before elf_section_reloc_link_order().

However, the relocation space required by elf_section_reloc_link_order()
is not accounted for when elf_link_size_reloc_section()
allocates relocation space.

If you look at the equivalent code in binutils-2.7 (which
doesn't have the bug), I think you'll find that the count was
held exclusively in o->reloc_count. Remnants of that code remain
as the first loop in elf_bfd_final_link() which updates o->reloc_count.

In binutils-2.7, o->reloc_count was used to size the relocation
area. Now, the relocation area is sized by
elf_section_data(o)->rel_count and elf_section_area(o)->rel_count2,
and I think you'll find that at the place I inserted the
BFD_ASSERT() in my patch:

        o->reloc_count != elf_section_data(o)->rel_count +
                          elf_section_data(o)->rel_count2;

In other words, the counts are inconsistent.

So, I believe that the bug is that the relocation size counts
fed to elf_link_size_reloc_section() is incorrect, and the
appropriate fix is to correct the way the counts are
maintained and updated.

Earl