Symbol merging for MIPS*/ELF

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

Hi,

 Due to SHN_MIPS_* weirdness, there appears to be a problem with merging
of versioned symbols that reside in one of these special sections.  It
manifests when the same symbol is defined as weak in one of input files
and as a strong in another one.  When it happens, the hash of the
non-versioned link (bfd_link_hash_indirect) to the real symbol has the
root.u.i.link field set to itself resulting in bfd locking up in an
indefinite loop.  The reason of this behaviour is the fact of
section.owner being null for these special sections, which in turn
defeats the code within elf_merge_symbol() that tries to detect a symbol
being merged with itself.

 The attached patch addresses the issue be moving the symbols back into
their respective sections.  This should make no problems because they will
be moved back into special sections on output if needed.

 Why do we bother to put symbols into SHN_MIPS_*, anyway? -- the ABI
states they are only used by some kind of profiler (I presume to mark the
symbols as already optimized) and, moreover, binaries that contain these
sections are not compliant. 

 Any comments are welcomed.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

diff -u --recursive --new-file binutils.macro/bfd/elf-bfd.h binutils/bfd/elf-bfd.h
--- binutils.macro/bfd/elf-bfd.h	Fri Sep 24 14:09:19 1999
+++ binutils/bfd/elf-bfd.h	Wed Nov 10 01:40:09 1999
@@ -1000,6 +1000,7 @@
 extern int _bfd_elf_symbol_from_bfd_symbol PARAMS ((bfd *, asymbol **));
 
 asection *bfd_section_from_elf_index PARAMS ((bfd *, unsigned int));
+asection *bfd_section_from_elf_name PARAMS ((bfd *, const char *));
 boolean _bfd_elf_create_dynamic_sections PARAMS ((bfd *,
 						  struct bfd_link_info *));
 struct bfd_strtab_hash *_bfd_elf_stringtab_init PARAMS ((void));
diff -u --recursive --new-file binutils.macro/bfd/elf.c binutils/bfd/elf.c
--- binutils.macro/bfd/elf.c	Mon Oct  4 16:31:21 1999
+++ binutils/bfd/elf.c	Wed Nov 10 01:41:20 1999
@@ -1345,6 +1345,23 @@
   return elf_elfsections (abfd)[index]->bfd_section;
 }
 
+/* Given an ELF section name, retrieve the corresponding BFD
+   section.  */
+
+asection *
+bfd_section_from_elf_name (abfd, name)
+     bfd *abfd;
+     const char *name;
+{
+  unsigned int i;
+
+  for (i = 1; i < elf_elfheader (abfd)->e_shnum; i++)
+    if (strcmp (bfd_section_from_elf_index (abfd, i)->name, name) == 0)
+      break;
+  BFD_ASSERT (i < elf_elfheader (abfd)->e_shnum);
+  return bfd_section_from_elf_index (abfd, i);
+}
+
 boolean
 _bfd_elf_new_section_hook (abfd, sec)
      bfd *abfd;
diff -u --recursive --new-file binutils.macro/bfd/elf32-mips.c binutils/bfd/elf32-mips.c
--- binutils.macro/bfd/elf32-mips.c	Fri Oct  8 16:41:22 1999
+++ binutils/bfd/elf32-mips.c	Wed Nov 10 01:44:23 1999
@@ -3072,6 +3072,7 @@
 static asymbol mips_elf_acom_symbol;
 static asymbol *mips_elf_acom_symbol_ptr;
 
+#if 0
 /* The Irix 5 support uses two virtual sections, which represent
    text/data symbols defined in dynamic objects.  */
 static asection mips_elf_text_section;
@@ -3083,6 +3084,7 @@
 static asection *mips_elf_data_section_ptr;
 static asymbol mips_elf_data_symbol;
 static asymbol *mips_elf_data_symbol_ptr;
+#endif
 
 /* Handle the special MIPS section numbers that a symbol may use.
    This is used for both the 32-bit and the 64-bit ABI.  */
@@ -3859,6 +3861,7 @@
       break;
 
     case SHN_MIPS_TEXT:
+#if 0
       /* This section is used in a shared object.  */
       if (mips_elf_text_section_ptr == NULL)
 	{
@@ -3878,11 +3881,22 @@
          info->shared.  I don't know why, and that doesn't make sense,
          so I took it out.  */
       *secp = mips_elf_text_section_ptr;
+#else
+      /* Find a corresponding .text section.  */
+      *secp = bfd_section_from_elf_name (abfd, ".text");
+#endif
       break;
 
     case SHN_MIPS_ACOMMON:
+#if 0
       /* Fall through. XXX Can we treat this as allocated data?  */
+#else
+      /* Find a corresponding .acommon section.  */
+      *secp = bfd_section_from_elf_name (abfd, ".acommon");
+      break;
+#endif
     case SHN_MIPS_DATA:
+#if 0
       /* This section is used in a shared object.  */
       if (mips_elf_data_section_ptr == NULL)
 	{
@@ -3902,6 +3916,10 @@
          info->shared.  I don't know why, and that doesn't make sense,
          so I took it out.  */
       *secp = mips_elf_data_section_ptr;
+#else
+      /* Find a corresponding .data section.  */
+      *secp = bfd_section_from_elf_name (abfd, ".data");
+#endif
       break;
 
     case SHN_MIPS_SUNDEFINED: