This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Symbol merging for MIPS*/ELF


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]