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.
* 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
(I wonder what other incompatibilities may exist between this new ABI
and the current binutils MIPS ELF headers...)
Chris Demetriou Broadcom Corporation
Senior Staff Design Engineer Broadband Processor Business Unit
Any opinions expressed in this message are mine, not necessarily Broadcom's.