From: Ralf Baechle <ralf@uni-koblenz.de>
To: Ian Lance Taylor <ian@zembu.com>
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
Subject: Re: Symbol merging for MIPS*/ELF
Date: Thu, 11 Nov 1999 15:00:00 -0000 [thread overview]
Message-ID: <19991111115437.A19641@uni-koblenz.de> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~1999-11-11 15:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-10 3:19 Maciej W. Rozycki
1999-11-10 7:56 ` Ian Lance Taylor
1999-11-11 15:00 ` Ralf Baechle [this message]
1999-11-15 1:45 ` Maciej W. Rozycki
1999-11-16 14:22 ` Ralf Baechle
1999-11-17 4:14 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19991111115437.A19641@uni-koblenz.de \
--to=ralf@uni-koblenz.de \
--cc=aj@suse.de \
--cc=binutils@sourceware.cygnus.com \
--cc=flo@rfc822.org \
--cc=hjl@lucon.org \
--cc=ian@zembu.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@vger.rutgers.edu \
--cc=linux@engr.sgi.com \
--cc=macro@ds2.pg.gda.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).