From: David Anderson <davea@quasar.engr.sgi.com>
To: hjl@lucon.org, cgd@broadcom.com
Cc: davea@quasar.engr.sgi.com, binutils@sources.redhat.com,
linux-mips@oss.sgi.com, linux-mips@fnet.fr,
"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
"Carsten Langgaard" <carstenl@mips.com>
Subject: Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)
Date: Thu, 25 Jul 2002 15:01:00 -0000 [thread overview]
Message-ID: <200207251850.LAA25513@quasar.engr.sgi.com> (raw)
In-Reply-To: <mailpost.1027610779.9546@news-sj1-1>
Chris Demetriou cgd@broadcom.com writes:
>[ Added David Anderson (hopefully still 8-) @ SGI to the CC list,
>since he's been helpful with sorting out questions like this in the
>past.
>
>At Thu, 25 Jul 2002 15:26:19 +0000 (UTC), "H. J. Lu" wrote:
>
>> I'd like to fix binutils ASAP. Here is a patch.
>
>People using stock binutils have been using the current binutils MIPS
>arch values for a While now. They were in 2.11.1 and later binutils
>releases, as well.
>
>
>> > /* ELF header e_flags defines. MIPS architecture level. */
>> > #define EF_MIPS_ARCH_1 0x00000000 /* -mips1 code. */
>> > #define EF_MIPS_ARCH_2 0x10000000 /* -mips2 code. */
>> > #define EF_MIPS_ARCH_3 0x20000000 /* -mips3 code. */
>> > #define EF_MIPS_ARCH_4 0x30000000 /* -mips4 code. */
>> > #define EF_MIPS_ARCH_5 0x40000000 /* -mips5 code. */
>> > #define EF_MIPS_ARCH_32 0x60000000 /* MIPS32 code. */
>> > #define EF_MIPS_ARCH_64 0x70000000 /* MIPS64 code. */
>> > #define EF_MIPS_ARCH_32R2 0x80000000 /* MIPS32 code. */
>> > #define EF_MIPS_ARCH_64R2 0x90000000 /* MIPS64 code. */
>
>Why are 2 definitions of MIPS32 and MIPS64 needed?
>
>Certainly, if you do need different definitions, they need much better
>comments than that.
>
>
>> > The missing value 0x50000000, is because IRIX has defined a EF_MIPS_ARCH_6
>> > and Algorithmics has a E_MIPS_ARCH_ALGOR_32, which has this value.
The latest IRIX def (not yet released header fragment):
elf.h:#define EF_MIPS_ARCH 0xf0000000 /* mask: 4 bit field */
elf.h:#define EF_MIPS_ARCH_1 0x00000000 /* MIPS I ISA */
elf.h:#define EF_MIPS_ARCH_2 0x10000000 /* MIPS II ISA */
elf.h:#define EF_MIPS_ARCH_3 0x20000000 /* MIPS III ISA */
elf.h:#define EF_MIPS_ARCH_4 0x30000000 /* MIPS IV ISA */
elf.h:#define EF_MIPS_ARCH_5 0x40000000 /* MIPS V ISA */
elf.h:#define EF_MIPS_ARCH_6 0x50000000
elf.h:#define EF_MIPS_ARCH_32 0x50000000 /* MIPS32 ISA */
elf.h:#define EF_MIPS_ARCH_64 0x60000000 /* MIPS64 ISA */
EF_MIPS_ARCH_32 duplicates EF_MIPS_ARCH_6 for basically historical
reasons I think : we did not want some compile to fail for no good reason
if EF_MIPS_ARCH_6 was referred to.
We never have used EF_MIPS_ARCH_6 for anything.
The EF_MIPS_ARCH_64 0x60000000
we got from binutils(!) around Nov 2001, according to my
email records. Without much certainty it was the right value.
>It's unfortunate that MIPS is only at this late stage getting into the
>business of defining these fields.
>
>Has IRIX actually _used_ EF_MIPS_ARCH_6 for anything (shipped)? That
>i'm a bit concerned about, since interoperability with IRIX would be a
>good thing given that SGI has been setting the only ABI example to
>follow for MIPS.
No, IRIX never used EF_MIPS_ARCH_6 0x50000000 for anything
shipped.
>Algorithmics may have done something different, but they have also
>been capable of contributing their binutils-related changes back to
>the binutils projects, yet they have not. Why muck things up for
>people who _have_, or who've been using the tools, on their account?
Nor have we shipped EF_MIPS_ARCH_32 or EF_MIPS_ARCH_64
(from the IRIX set above).
While I cannot speak for everyone here, I'm pretty sure that
we can follow what is eventually adopted, since the values in question
represent nothing shipped.
We added EF_MIPS_ARCH_5 0x40000000
and EF_MIPS_ARCH_6 0x50000000 to elf.h
long long ago.
I don't *think* we've shipped EF_MIPS_ARCH_5 0x40000000
either, but I could well be wrong on that, I forget
what was said/done on EF_MIPS_ARCH_5. If it matters
I could check (let me know).
I've added a couple key interested sgi folks (via bcc,
I don't know they want email addresses exposed) to this
response. So if I've made mistakes above such can
get corrrected.
Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea
next prev parent reply other threads:[~2002-07-25 18:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.3.96.1020725125830.27463H-100000@delta.ds2.pg.gda.pl>
[not found] ` <3D3FFD21.8DA26337@mips.com>
2002-07-25 9:17 ` H. J. Lu
[not found] ` <mailpost.1027610779.9546@news-sj1-1>
2002-07-25 11:54 ` cgd
2002-07-25 15:01 ` David Anderson [this message]
2002-07-26 9:59 ` cgd
2002-07-26 10:37 ` Paul Koning
2002-07-29 2:22 ` PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework) Carsten Langgaard
2002-07-30 8:06 ` Dan Temple
2002-07-30 8:36 ` Maciej W. Rozycki
[not found] ` <mailpost.1028038253.3155@news-sj1-1>
2002-07-30 12:26 ` PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) cgd
2002-07-30 12:27 ` Geoff Keating
2002-07-30 13:05 ` cgd
2002-07-30 13:13 ` Eric Christopher
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=200207251850.LAA25513@quasar.engr.sgi.com \
--to=davea@quasar.engr.sgi.com \
--cc=binutils@sources.redhat.com \
--cc=carstenl@mips.com \
--cc=cgd@broadcom.com \
--cc=hjl@lucon.org \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.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).