* PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) [not found] ` <3D3FFD21.8DA26337@mips.com> @ 2002-07-25 9:17 ` H. J. Lu [not found] ` <mailpost.1027610779.9546@news-sj1-1> 0 siblings, 1 reply; 12+ messages in thread From: H. J. Lu @ 2002-07-25 9:17 UTC (permalink / raw) To: Carsten Langgaard; +Cc: Maciej W. Rozycki, linux-mips, linux-mips, binutils [-- Attachment #1: Type: text/plain, Size: 3573 bytes --] I'd like to fix binutils ASAP. Here is a patch. On Thu, Jul 25, 2002 at 03:29:12PM +0200, Carsten Langgaard wrote: > "Maciej W. Rozycki" wrote: > > > On Wed, 24 Jul 2002, Carsten Langgaard wrote: > > > > > We at MIPS are in the process of making an ABI spec for all this, which > > > is the intention that should be used by the tool-vendors. So please > > > don't change the ELF header defines. > > > > It'd be better the spec matched the real world... > > Shouldn't it be the other way around, the real world should follow the spec > ;-) > The whole ELF header definition is just one big mess, because we are lacking > a proper ABI spec. > That's what has motivated us, to begin making this ABI spec. > > We have defined the e_flags this way: > > /* 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. */ > > 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. > If you look at the elf.h file in glibc, the you will see, it has the same > values as the kernel. > > So I would prefer we fix that in binutils, I guess it not a problem as long > as you don't have a toolchain that can generate MIPS32 or MIPS64 code. > > > > > > > I don't see that is wrong with checking the ISA level, I rather have an > > > error telling me that I can't execute a certain ISA level than > > > eventually getting a reserved instruction or something worse like > > > something unpredictable. > > > > Well, -ENOEXEC in not any more useful than SIGILL -- with the latter you > > have at least an idea what happened. The ISA check is not implemented for > > any Linux port, so there no suitable hook in binfmt_*.c files. You might > > propose an implementation if that's particularly important for you. > > > > I would like a message telling me that I can't run this ISA level on the > system. > Imagined what would happen, if you execute mips3 code and execute ld/sd > instructions on a mips32 kernel (but on a 64-bit processor), the kernel only > save half the register and then everything could happen. > > > > > > > You are obviously right about the elf_check_arch in the 64-bit part of > > > the kernel is broken. It's probably just be copied from the 32-bit part > > > without changes, like a lot of the code in the 64-bit kernel is. > > > > Possibly, but it still makes me wonder why it wasn't adjusted at the time > > binfmt_elf32.c was created... > > > > Maciej > > > > -- > > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > > +--------------------------------------------------------------+ > > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > [-- Attachment #2: elf-mips.patch --] [-- Type: text/plain, Size: 1023 bytes --] 2002-07-25 H.J. Lu <hjl@gnu.org> * mips.h (E_MIPS_ARCH_6): New. (E_MIPS_ARCH_ALGOR_32): New. (E_MIPS_ARCH_32): Changed. (E_MIPS_ARCH_64): Changed. (E_MIPS_ARCH_32R2): New. (E_MIPS_ARCH_64R2): New. --- include/elf/mips.h.mips Fri Sep 7 15:43:58 2001 +++ include/elf/mips.h Thu Jul 25 08:21:10 2002 @@ -139,11 +139,23 @@ END_RELOC_NUMBERS (R_MIPS_maxext) /* -mips5 code. */ #define E_MIPS_ARCH_5 0x40000000 +/* Used by IRIX. */ +#define E_MIPS_ARCH_6 0x50000000 + +/* Used by Algorithmics. */ +#define E_MIPS_ARCH_ALGOR_32 0x50000000 + /* -mips32 code. */ -#define E_MIPS_ARCH_32 0x50000000 +#define E_MIPS_ARCH_32 0x60000000 /* -mips64 code. */ -#define E_MIPS_ARCH_64 0x60000000 +#define E_MIPS_ARCH_64 0x70000000 + +/* MIPS32 code. */ +#define E_MIPS_ARCH_32R2 0x80000000 + +/* MIPS64 code. */ +#define E_MIPS_ARCH_64R2 0x90000000 /* The ABI of the file. Also see EF_MIPS_ABI2 above. */ #define EF_MIPS_ABI 0x0000F000 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <mailpost.1027610779.9546@news-sj1-1>]
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) [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 2 siblings, 0 replies; 12+ messages in thread From: cgd @ 2002-07-25 11:54 UTC (permalink / raw) To: hjl Cc: Carsten Langgaard, Maciej W. Rozycki, linux-mips, linux-mips, binutils, davea [ 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) [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 2 siblings, 0 replies; 12+ messages in thread From: David Anderson @ 2002-07-25 15:01 UTC (permalink / raw) To: hjl, cgd Cc: davea, binutils, linux-mips, linux-mips, Maciej W. Rozycki, Carsten Langgaard 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) [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 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 2 siblings, 2 replies; 12+ messages in thread From: cgd @ 2002-07-26 9:59 UTC (permalink / raw) To: hjl Cc: Carsten Langgaard, Maciej W. Rozycki, linux-mips, linux-mips, binutils 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) 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 1 sibling, 0 replies; 12+ messages in thread From: Paul Koning @ 2002-07-26 10:37 UTC (permalink / raw) To: cgd; +Cc: hjl, carstenl, macro, linux-mips, linux-mips, binutils >>>>> "cgd" == cgd <cgd@broadcom.com> writes: cgd> 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. cgd> OK, so, I've seen no response so far that indicates that cgd> binutils should actually be changed. Agreed, for all the reasons you so clearly stated. paul ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework) 2002-07-26 9:59 ` cgd 2002-07-26 10:37 ` Paul Koning @ 2002-07-29 2:22 ` Carsten Langgaard 2002-07-30 8:06 ` Dan Temple 1 sibling, 1 reply; 12+ messages in thread From: Carsten Langgaard @ 2002-07-29 2:22 UTC (permalink / raw) To: cgd; +Cc: hjl, Maciej W. Rozycki, linux-mips, linux-mips, binutils First of all I will like to thank you for all the replies, we really appreciate it, because it helps us in our process of making a proper ABI spec. I known it's a relative late state we are trying to provide the community with an ABI document, but I guess it's better to be late than to never show up. I believe we all could benefit from such a document, it's only in a internal draft version right now, but it might be a good idea to send it out to the community for comments, before the finally version. But we are still in an early state and on the learning curve. Regarding the ELF header arch values, we did try to select whose in order not to break things for anyone. I'm also a little surprised to see these value out in binutils, it really surprise me, if we got a linux toolchain that can generate mips32/mips64 code. MIPS32R2 and MIPS64R2 is a new enhanced version of MIPS32 and MIPS64 architecture, which among other things include some new instructions. Regarding Algorithmics, I don't know if everybody are aware of it, but we have just acquired Algorithmics. That among other things, is done in order to play a stronger part in the development of the toolchain. And their work will be pushed back to the community. Algorithmics have done a MIPS32 compiler for us, which is very close to be released. I hope this clarify a little bit, what our motivation are. /Carsten cgd@broadcom.com wrote: > 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. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework) 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> 0 siblings, 2 replies; 12+ messages in thread From: Dan Temple @ 2002-07-30 8:06 UTC (permalink / raw) To: Carsten Langgaard; +Cc: cgd, hjl, Maciej W. Rozycki, linux-mips, binutils I've now heard a bit of the history from Nigel at Algorithmics, and to summarize, they chose the 6 and 7 values for MIPS32/64 after Cygnus, who were also producing a MIPS32/64 toolchain, had chosen these. (Algor had originally used the value of 5 for MIPS32, but had to changed when both SGI (who assigned it to something else) and Cygnus chose otherwise). Hence ARCH_ALGOR_32. A little research also reveals that the value of 5 for ARCH_32 was first checked into CVS in Dec 2000 by Nick Clifton at Redhat. Anyway, that's why things are the way they are, but may not help much as to a resolution :( My personal take on this is that the two main commercial providers (Cygnus and Algor) of MIPS32/64-capable GNU toolchains have been using 6 & 7 for quite a while, SGI "agree", and that this is quite a precedent. Hopefully the ABI process will soon shake any other issues out too. /Dan On Mon, 29 Jul 2002, Carsten Langgaard wrote: > First of all I will like to thank you for all the replies, we really appreciate > it, because it helps us in our process of making a proper ABI spec. > I known it's a relative late state we are trying to provide the community with an > ABI document, but I guess it's better to be late than to never show up. > I believe we all could benefit from such a document, it's only in a internal draft > version right now, but it might be a good idea to send it out to the community for > comments, before the finally version. > But we are still in an early state and on the learning curve. > > Regarding the ELF header arch values, we did try to select whose in order not to > break things for anyone. > I'm also a little surprised to see these value out in binutils, it really surprise > me, if we got a linux toolchain that can generate mips32/mips64 code. > > MIPS32R2 and MIPS64R2 is a new enhanced version of MIPS32 and MIPS64 architecture, > which among other things include some new instructions. > > Regarding Algorithmics, I don't know if everybody are aware of it, but we have > just acquired Algorithmics. > That among other things, is done in order to play a stronger part in the > development of the toolchain. And their work will be pushed back to the community. > > Algorithmics have done a MIPS32 compiler for us, which is very close to be > released. > > I hope this clarify a little bit, what our motivation are. > /Carsten > > > cgd@broadcom.com wrote: > > > 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. > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > > -- Dan Temple, Eng. Mgr. Tel: +45-44865512 MIPS Denmark Fax: +45-44865556 Lautrupvang 4B mailto:dant@mips.com DK-2750 Ballerup http://www.mips.com Denmark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC:elf_check_arch() rework) 2002-07-30 8:06 ` Dan Temple @ 2002-07-30 8:36 ` Maciej W. Rozycki [not found] ` <mailpost.1028038253.3155@news-sj1-1> 1 sibling, 0 replies; 12+ messages in thread From: Maciej W. Rozycki @ 2002-07-30 8:36 UTC (permalink / raw) To: Dan Temple; +Cc: Carsten Langgaard, cgd, hjl, linux-mips, binutils On Tue, 30 Jul 2002, Dan Temple wrote: > I've now heard a bit of the history from Nigel at Algorithmics, and to > summarize, they chose the 6 and 7 values for MIPS32/64 after Cygnus, who > were also producing a MIPS32/64 toolchain, had chosen these. (Algor had > originally used the value of 5 for MIPS32, but had to changed when both > SGI (who assigned it to something else) and Cygnus chose otherwise). > Hence ARCH_ALGOR_32. > > A little research also reveals that the value of 5 for ARCH_32 was first > checked into CVS in Dec 2000 by Nick Clifton at Redhat. Hmm, the relevant ChangeLog entry is: 2000-10-16 Chris Demetriou <cgd@sibyte.com> * mips.h (E_MIPS_ARCH_32): New constant. (E_MIPS_MACH_MIPS32, E_MIPS_MACH_MIPS32_4K): Replace the former with the latter. * mips.h (E_MIPS_ARCH_5, E_MIPS_ARCH_64): New definitions. * mips.h (E_MIPS_MACH_SB1): New constant. Patches went in with two commits on Dec 1st and 2nd, 2000: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/include/elf/mips.h.diff?r1=1.8&r2=1.9&cvsroot=src http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/include/elf/mips.h.diff?r1=1.9&r2=1.10&cvsroot=src Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <mailpost.1028038253.3155@news-sj1-1>]
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) [not found] ` <mailpost.1028038253.3155@news-sj1-1> @ 2002-07-30 12:26 ` cgd 2002-07-30 12:27 ` Geoff Keating 2002-07-30 13:05 ` cgd 0 siblings, 2 replies; 12+ messages in thread From: cgd @ 2002-07-30 12:26 UTC (permalink / raw) To: dant; +Cc: Carsten Langgaard, hjl, Maciej W. Rozycki, linux-mips, binutils At Tue, 30 Jul 2002 14:10:53 +0000 (UTC), "Dan Temple" wrote: > I've now heard a bit of the history from Nigel at Algorithmics, and > to summarize, they chose the 6 and 7 values for MIPS32/64 after > Cygnus, who were also producing a MIPS32/64 toolchain, had chosen > these. (Algor had originally used the value of 5 for MIPS32, but had > to changed when both SGI (who assigned it to something else) and > Cygnus chose otherwise). Hence ARCH_ALGOR_32. Uh, i believe i've seen a snapshot of the Cygnus MIPS32/64 toolchain you describe. It was described to me as an "alpha" snapshot. I have no reason to believe it was ever released as a commercial-quality product. I've made an inquiry, and my understanding is that Cygnus/RedHat internally use the same values as the public tools (i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6). > My personal take on this is that the two main commercial providers > (Cygnus and Algor) of MIPS32/64-capable GNU toolchains have been > using 6 & 7 for quite a while, As noted above, at least for Cygnus, I believe this assertion is not correct. > SGI "agree", with the current master binutils sources. 8-) As noted in the message: http://sources.redhat.com/ml/binutils/2002-07/msg00681.html SGI is using the same values as the master public GNU binutils, i.e. MIPS32 == 5, MIPS64 == 6. It sounds like it wouldn't hurt them much to switch, but following your suggestion _would_ involve them switching. > and that this is quite a > precedent. The precedent that I see here is: * the public master GNU tool sources use EF_MIPS_ARCH_32 == 5, EF_MIPS_ARCH_64 == 6. * Cygnus/RedHat uses those same values. * SGI also uses those same values. * A fair number of other GNU tool or OS support houses have also picked up those values and use them. * Algorithmics uses different values. The meaning of their 'ALGOR_32' arch value hasn't been mentioned here, I don't know what it is. But, given that everybody else uses the values that the current GNU tools do, well, they should probably provide some backward compatibility for their users if they want it, and switch. (Heck, I don't even know that 'ALGOR_32' should be different than '32' to begin with.) > Hopefully the ABI process will soon shake any other > issues out too. Indeed. I look forward to seeing a published ABI proposal. I strongly encourage you to announce the proposal to other groups than just the Linux MIPS folks, by the way. For instance, NetBSD is likely to want to adopt the same ABI for MIPS platforms, and it would be good if they were able to participate in the process as well. I'd recommend contacting <port-mips@netbsd.org> (the NetBSD/mips platform-independent development list), and specifically Simon Burge <simonb@wasabisystems.com> who I believe personally has an interest in this stuff. 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) 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 1 sibling, 0 replies; 12+ messages in thread From: Geoff Keating @ 2002-07-30 12:27 UTC (permalink / raw) To: cgd; +Cc: dant, carstenl, hjl, macro, linux-mips, binutils > From: cgd@broadcom.com > Date: 30 Jul 2002 12:20:57 -0700 > Uh, i believe i've seen a snapshot of the Cygnus MIPS32/64 toolchain > you describe. It was described to me as an "alpha" snapshot. I have > no reason to believe it was ever released as a commercial-quality > product. It was. -- - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) 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 1 sibling, 1 reply; 12+ messages in thread From: cgd @ 2002-07-30 13:05 UTC (permalink / raw) To: dant; +Cc: Carsten Langgaard, hjl, Maciej W. Rozycki, linux-mips, binutils At 30 Jul 2002 12:20:57 -0700, Chris G. Demetriou wrote: > I've made an inquiry, and my understanding is that Cygnus/RedHat > internally use the same values as the public tools > (i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6). Of course, i typo'd most of the names of the constants in my msg. I meant E_MIPS_ARCH_32, etc., obviously. 8-) chris ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: PATCH: Update E_MIP_ARCH_XXX (Re: [patch] linux: RFC: elf_check_arch() rework) 2002-07-30 13:05 ` cgd @ 2002-07-30 13:13 ` Eric Christopher 0 siblings, 0 replies; 12+ messages in thread From: Eric Christopher @ 2002-07-30 13:13 UTC (permalink / raw) To: cgd; +Cc: dant, Carsten Langgaard, hjl, Maciej W. Rozycki, linux-mips, binutils On Tue, 2002-07-30 at 12:27, cgd@broadcom.com wrote: > At 30 Jul 2002 12:20:57 -0700, Chris G. Demetriou wrote: > > I've made an inquiry, and my understanding is that Cygnus/RedHat > > internally use the same values as the public tools > > (i.e. EF_MIPS_ARCH_MIPS32 == 5, ..._MIPS64 == 6). > > Of course, i typo'd most of the names of the constants in my msg. I > meant E_MIPS_ARCH_32, etc., obviously. 8-) We have nothing different from what the sources on the net use. -eric -- I don't want a pony, I want a rocket powered jetpack! ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-07-30 20:05 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 ` 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 11:54 ` cgd 2002-07-25 15:01 ` David Anderson 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
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).