Re: PR 10629, mips irix6 assert and segfault

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Thu, 15 Oct 2009, Richard Sandiford wrote:

> 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.

 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
       pointer.

     * 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 [1].  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 
fixes:

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.

  Maciej

[1] http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=&db=man&fname=/usr/share/catman/u_man/cat1/rld.z

2012-11-28  "Maciej W. Rozycki  <macro@codesourcery.com>

	bfd/
	PR ld/10629
	* elfxx-mips.c (mips_elf_link_hash_table): Update comment for
	use_rld_obj_head.
	(_bfd_mips_elf_create_dynamic_sections): Always create a
	.rld_map section if no __rld_obj_head symbol has been seen.

binutils-bfd-mips-irix6-rld-obj-head.diff
Index: binutils-fsf-trunk-quilt/bfd/elfxx-mips.c
===================================================================
--- 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).  */
   bfd_size_type compact_rel_size;
 
-  /* 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.  */
   bfd_boolean use_rld_obj_head;
 
   /* The  __rld_map or __rld_obj_head symbol. */
@@ -7293,7 +7293,7 @@ _bfd_mips_elf_create_dynamic_sections (b
     return FALSE;
   htab->sstubs = s;
 
-  if ((IRIX_COMPAT (abfd) == ict_irix5 || IRIX_COMPAT (abfd) == ict_none)
+  if (!mips_elf_hash_table (info)->use_rld_obj_head
       && !info->shared
       && bfd_get_linker_section (abfd, ".rld_map") == NULL)
     {