This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Symbol merging for MIPS*/ELF
- To: macro at ds2 dot pg dot gda dot pl
- Subject: Re: Symbol merging for MIPS*/ELF
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 10 Nov 1999 10:55:46 -0500
- CC: binutils at sourceware dot cygnus dot com, hjl at lucon dot org, aj at suse dot de, ralf at uni-koblenz dot de, flo at rfc822 dot org
- References: <Pine.GSO.3.96.991110115952.9984B-100000@delta.ds2>
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