public inbox for binutils@sourceware.org
 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
Subject: Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework)
Date: Fri, 26 Jul 2002 09:59:00 -0000	[thread overview]
Message-ID: <yov54remph1v.fsf@broadcom.com> (raw)
In-Reply-To: hjl@lucon.org's message of "Thu, 25 Jul 2002 15:26:19 +0000 (UTC)"

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.

OK, so, I've seen no response so far that indicates that binutils
should actually be changed.


to recap:

* Binutils has deployed these values in several releases now, and I
  know for a fact that people are using binaries with these values.

* SGI has followed binutils' lead in selecting values.

* Algorithmics did something else, though it's not clear what the
  difference between "ARCH_ALGOR_32" and "ARCH_32" really is.


It seems obvious that the simplest solution that causes the least pain
all around is to go with the numbering binutils currently uses.  This
will probably cause a little bit of pain for Algorithmics, but, well,
they could have sent something to binutils to indicate use of that
number, and i'm quite sure that most of the rest of us have had to put
temporary backward-compat hacks in our own codebases for incompatible
changes made by others in the past.  It's not that hard and doesn't
cause long-term pain.


I could understand that MIPS or Algorithmics might like that, but I
think there're a bunch of morals to this story: if you want to lead on
ABI issues, get out in front of them (you can't lead from the back
8-); interact with the tool development and use communities about such
issues _before_ solutions are needed and agreed upon in those
communities; and, you're hacking open source code like binutils,
contribute your changes back as soon as you possibly can.

I'd also like to point out that saying "mips will be defining this
ABI, so you should all change your code to work with it" without,
AFAIK, even providing a draft of said ABI... is unlikely to produce
positive results even _if_ there's no precedent that would go against
the requested change.  (if somebody has a ptr, i'd be glad to be
corrected 8-)

(I wonder what other incompatibilities may exist between this new ABI
and the current binutils MIPS ELF headers...)



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-26 16:53 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
2002-07-26  9:59       ` cgd [this message]
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=yov54remph1v.fsf@broadcom.com \
    --to=cgd@broadcom.com \
    --cc=binutils@sources.redhat.com \
    --cc=carstenl@mips.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).