linux-mips-fnet
[Top] [All Lists]

Re: Symbol merging for MIPS*/ELF

To: Ian Lance Taylor <ian@zembu.com>
Subject: Re: Symbol merging for MIPS*/ELF
From: Ralf Baechle <ralf@uni-koblenz.de>
Date: Thu, 11 Nov 1999 11:54:37 +0100
Cc: macro@ds2.pg.gda.pl, binutils@sourceware.cygnus.com, hjl@lucon.org, aj@suse.de, flo@rfc822.org, linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
In-reply-to: <19991110155546.14856.qmail@daffy.airs.com>
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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Symbol merging for MIPS*/ELF, Ralf Baechle <=