Symbol merging for MIPS*/ELF

Symbol merging for MIPS*/ELF

[Maciej W. Rozycki]

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:

Re: Symbol merging for MIPS*/ELF

[Ian Lance Taylor]

   Date: Wed, 10 Nov 1999 12:19:22 +0100 (MET)
   From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>

    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.

Can you use bfd_get_section_by_name instead of introducing
bfd_section_from_elf_name?

What happens if the section you are looking (.text or .data) for is
not present?  Is there any reason to assume that it must be present?

    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. 

Those patches were from Kazumoto Kojima
<kkojima@info.kanagawa-u.ac.jp>, and were intended to support dynamic
linking for MIPS GNU/Linux.  It may be that we should not be
generating SHN_MIPS_TEXT and SHN_MIPS_DATA in output files.  This may
be an Irix specific thing.  I don't know.

Ian

Re: Symbol merging for MIPS*/ELF

[Ralf Baechle]

On Wed, Nov 10, 1999 at 10:55:46AM -0500, Ian Lance Taylor wrote:

> Those patches were from Kazumoto Kojima
> <kkojima@info.kanagawa-u.ac.jp>, and were intended to support dynamic
> linking for MIPS GNU/Linux.  It may be that we should not be
> generating SHN_MIPS_TEXT and SHN_MIPS_DATA in output files.  This may
> be an Irix specific thing.  I don't know.

I just checked this in the blue books from AT&T.  It defines SHN_MIPS_ACOMMON
(0xff00), SHN_MIPS_SCOMMON (0xff03), SHN_MIPS_SUNDEFINED (0xff04).  0xff01
and 0xff02 are reserved values.  I guess the blue books are equivalent to
ABI version 1.0.

The current MIPS ABI 3.0 then defines SHM_MIPS_TEXT as 0xff01 and
SHM_MIPS_DATA as 0xff02 with the following explanation:

  Symbols defined relative to these two sections are only present after a
  program has been rewritten by the pixie code profiling program.  Such
  rewritten programs are not ABI-compliant.  Symbols defined relative to
  these sections will never occur in an ABI-compliant program.

I cc this to the various Linux/MIPS mailing lists.  A number of the people
who did work on the MIPS ABI and it's implementations are reading there.
Maybe somebody can bring more light into this, especially the reasons for
this SHN_MIPS_* magic.

  Ralf

Re: Symbol merging for MIPS*/ELF

[Maciej W. Rozycki]

On 10 Nov 1999, Ian Lance Taylor wrote:

> Can you use bfd_get_section_by_name instead of introducing
> bfd_section_from_elf_name?

 No I can't.  abfd->sections might be nullified at the moment (search
elflink.h for "We do not want to include any of the sections" to see where
it happens) and bfd_get_section_by_name wouldn't return anything useful.
Hence, bfd_section_from_elf_name obtains sections from ELF headers (it's
derived from bfd_section_from_elf_index, actually).

> What happens if the section you are looking (.text or .data) for is
> not present?  Is there any reason to assume that it must be present?

 I presume if SHN_MIPS_* are used, the respective sections are present (at
least this seems to be always the case when using BFD).  But I cannot
write anything of MIPS tools from other vendors.  Let MIPS people comment
on this.  I put an assertion to detect such cases, anyway.

> Those patches were from Kazumoto Kojima
> <kkojima@info.kanagawa-u.ac.jp>, and were intended to support dynamic
> linking for MIPS GNU/Linux.  It may be that we should not be
> generating SHN_MIPS_TEXT and SHN_MIPS_DATA in output files.  This may
> be an Irix specific thing.  I don't know.

 Well, it looks like other Linux ports can live without special sections
and still they support dynamic linking.  I suppose they exist to allow
Linux binaries to be run on some other MIPS operating system. 

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

Re: Symbol merging for MIPS*/ELF

[Ralf Baechle]

On Mon, Nov 15, 1999 at 10:43:59AM +0100, Maciej W. Rozycki wrote:

>  Well, it looks like other Linux ports can live without special sections
> and still they support dynamic linking.  I suppose they exist to allow
> Linux binaries to be run on some other MIPS operating system. 

To my knowledge there is no operating system that can run Linux/MIPS
binaries.

  Ralf

Re: Symbol merging for MIPS*/ELF

[Maciej W. Rozycki]

On Tue, 16 Nov 1999, Ralf Baechle wrote:

> To my knowledge there is no operating system that can run Linux/MIPS
> binaries.

 Then, possibly, these sections could be avoided when generating binaries 
for Linux.  I am not sure how this option be presented to user, though.  A 
lone switch to ld, etc. is obviously insufficient; it should have to be
settable via an ld script, too.  But then, what about other tools that
depend on BFD (objcopy, for example)?

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