Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: cgd@broadcom.com
To: hjl@lucon.org
Cc: "Carsten Langgaard" <carstenl@mips.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@fnet.fr, linux-mips@oss.sgi.com,
	binutils@sources.redhat.com, davea@quasar.engr.sgi.com
Subject: Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)
Date: 25 Jul 2002 10:49:30 -0700	[thread overview]
Message-ID: <yov5u1mny9xx.fsf@broadcom.com> (raw)
In-Reply-To: hjl@lucon.org's message of "Thu, 25 Jul 2002 15:26:19 +0000 (UTC)"

[ 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.

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.

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?




cgd
-- 
Chris Demetriou                                            Broadcom Corporation
Senior Staff Design Engineer                  Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.

  parent reply	other threads:[~2002-07-25 17:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-24 17:05 [patch] linux: RFC: elf_check_arch() rework Maciej W. Rozycki
2002-07-24 18:08 ` Daniel Jacobowitz
2002-07-24 19:12 ` Carsten Langgaard
2002-07-24 19:31   ` Daniel Jacobowitz
2002-07-25 11:10   ` Maciej W. Rozycki
2002-07-25 13:29     ` Carsten Langgaard
2002-07-25 14:12       ` Maciej W. Rozycki
2002-07-25 15:26       ` PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) H. J. Lu
     [not found]         ` <mailpost.1027610779.9546@news-sj1-1>
2002-07-25 17:49           ` cgd [this message]
2002-07-25 18:50           ` David Anderson
2002-07-26 16:53           ` cgd
2002-07-26 17:12             ` Paul Koning
2002-07-29  7:47             ` PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework) Carsten Langgaard
2002-07-29  7:47               ` Carsten Langgaard
2002-07-30 14:09               ` Dan Temple
2002-07-30 14:09                 ` Dan Temple
2002-07-30 15:07                 ` Maciej W. Rozycki
     [not found]                 ` <mailpost.1028038253.3155@news-sj1-1>
2002-07-30 19:20                   ` PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) cgd
2002-07-30 19:26                     ` Geoff Keating
2002-07-30 19:27                     ` cgd
2002-07-30 20:03                       ` 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=yov5u1mny9xx.fsf@broadcom.com \
    --to=cgd@broadcom.com \
    --cc=binutils@sources.redhat.com \
    --cc=carstenl@mips.com \
    --cc=davea@quasar.engr.sgi.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