Re: PR 10629, mips irix6 assert and segfault

[Richard Sandiford <rdsandiford at googlemail dot com>]

Alan Modra <amodra@bigpond.net.au> writes:
> I was looking at this PR the other day but soon realized I don't know
> enough about the mips ABIs to be confident of making a correct fix,
> and it doesn't help that www.mipsabi.org links to tech docs are all
> broken.
>
> The obvious problem leading to this pr is that
> _bfd_mips_elf_create_dynamic_sections does not create a .rld_map
> section when irix6 compatible, but a few lines later attempts to
> create a __rld_map symbol using the section.  The segfault is easy to
> fix by not creating the symbol, but then, how does DT_MIPS_RLD_MAP get
> set for irix6?

Well, I looked at some ABI docs, and I can't figure it out either.
The only mention of rld_map in SGI's ELF64 ABI seems to be in a list
of dynamic tags.  That list includes DT_MIPS_RLD_MAP as an optional tag,
but there seems to be no other mention of it in the rest of the document.
The implication is that this should be the same as for the 32-bit psABI,
which simply says that DT_MIPS_RLD_MAP points to a 32-bit data word that
is used for debugging, and that anything that relies on its value is not
conformant.  (Usual standardese, of course, and this is no doubt a
64-bit value in ELF64.)  Nothing talks about the .rld_map section or the
__rld_obj_head symbol.

My only guess is that __rld_obj_head is normally defined for IRIX6,
which would circumvent the guilty code.  That's hardly a good assumption
to make, but maybe we just got away with it.  Mark's patch makes it clear
that on IRIX 6 (unlike IRIX 5), this symbol is not always in the
.rld_map section:

    http://sourceware.org/ml/binutils/1999-q2/msg00373.html

I don't know where it is instead though.

However, I do remember GAS and GNU ld worked well enough a few years
back to pass GCC testing (probably in the binutils 2.15 timeframe)
and I can't see anything obvious that has changed in the meantime.
Someone with IRIX access is probably going to have to fix this.

Richard