This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Symbol merging for MIPS*/ELF
- To: Ian Lance Taylor <ian at zembu dot com>
- Subject: Re: Symbol merging for MIPS*/ELF
- From: Ralf Baechle <ralf at uni-koblenz dot de>
- Date: Thu, 11 Nov 1999 11:54:37 +0100
- Cc: macro at ds2 dot pg dot gda dot pl, binutils at sourceware dot cygnus dot com, hjl at lucon dot org, aj at suse dot de, flo at rfc822 dot org, linux at engr dot sgi dot com, linux-mips at fnet dot fr, linux-mips at vger dot rutgers dot edu
- References: <Pine.GSO.3.96.991110115952.9984B-100000@delta.ds2> <19991110155546.14856.qmail@daffy.airs.com>
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