This is the mail archive of the
mailing list for the binutils project.
Re: PR 10629, mips irix6 assert and segfault
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Alan Modra <amodra at gmail dot com>, <binutils at sourceware dot org>
- Date: Wed, 28 Nov 2012 00:20:55 +0000
- Subject: Re: PR 10629, mips irix6 assert and segfault
- References: <20091013231732.GM8054@bubble.grove.modra.org> <email@example.com>
On Thu, 15 Oct 2009, Richard Sandiford wrote:
> Alan Modra <firstname.lastname@example.org> 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:
> 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.
While I do not qualify as I have no IRIX access, I triggered this problem
with the mips-sgi-irix6 targets and the new test cases I have been working
on, and to avoid adding dozens of new failures I spent a few moments
looking into it. As a result I came across this:
"SYSTEM DEVELOPER'S INTERFACE
rld keeps a doubly linked list of structures. crt1.o contains a
pointer, __rld_obj_head, to the head of the list of object structures.
This pointer's targets depend on the ABI, as follows:
* For an old 32-bit executable, __rld_obj_head points to a linked list
of objList structures (/usr/include/obj_list.h). Each of these
structures has a data element that is a pointer to a struct obj
(/usr/include/obj.h), even though the field is not declared as a
* For a new 32-bit executable, __rld_obj_head points to a linked list
of Elf32_Obj_Info structures: /usr/include/objlist.h.
* For a 64-bit executable, __rld_obj_head points to a linked list of
Elf64_Obj_Info structures: /usr/include/objlist.h.
The oi_magic element of each Elf32_Obj_Info or Elf64_Obj_Info is all-
bits-on (0xffffffff) to make it easier to determine which list type in
use is a 32-bit executable."
in IRIX 6.5 rld(5) system manual . And it's not like that section of
the manual slipped through the system update or suchlike as it includes
explicit references to the n32 and n64 ABIs that were only added with IRIX
6 and not supported beforehand.
So it looks like your guess is indeed correct and we should simply assert
that just as with IRIX 5, the symbol is always present, and if not, then
the binary is non-compliant and we can do whatever we see fit. And in the
absence of the symbol we already add the .rld.map section to IRIX 5
binaries, so I suppose the outcome is not going to be any worse if we do
that for IRIX 6 too.
Therefore I propose the change below to address this problem. This
FAIL: reloc test 6b
for mips-sgi-irix6 and causes no regressions across the list of my usual
targets (whose count has now grown to 136). OK to apply?
I'm not sure if the original submitter can be bothered anymore as he
stopped responding even as the bug was being actively handled, but I think
we can safely mark it PR ld/10629 and tick off.
2012-11-28 "Maciej W. Rozycki <email@example.com>
* elfxx-mips.c (mips_elf_link_hash_table): Update comment for
(_bfd_mips_elf_create_dynamic_sections): Always create a
.rld_map section if no __rld_obj_head symbol has been seen.
--- binutils-fsf-trunk-quilt.orig/bfd/elfxx-mips.c 2012-11-27 17:58:12.000000000 +0000
+++ binutils-fsf-trunk-quilt/bfd/elfxx-mips.c 2012-11-27 21:31:42.451760227 +0000
@@ -432,8 +432,8 @@ struct mips_elf_link_hash_table
/* The size of the .compact_rel section (if SGI_COMPAT). */
- /* This flag indicates that the value of DT_MIPS_RLD_MAP dynamic
- entry is set to the address of __rld_obj_head as in IRIX5. */
+ /* This flag indicates that the value of DT_MIPS_RLD_MAP dynamic entry
+ is set to the address of __rld_obj_head as in IRIX5 and IRIX6. */
/* The __rld_map or __rld_obj_head symbol. */
@@ -7293,7 +7293,7 @@ _bfd_mips_elf_create_dynamic_sections (b
htab->sstubs = s;
- if ((IRIX_COMPAT (abfd) == ict_irix5 || IRIX_COMPAT (abfd) == ict_none)
+ if (!mips_elf_hash_table (info)->use_rld_obj_head
&& bfd_get_linker_section (abfd, ".rld_map") == NULL)