| Message ID | b88a98fa-b4de-9e76-c5a9-9201feb3b4d0@arm.com |
|---|---|
| State | New |
| Headers | show |
> The port is also *very* out-of-date. Not only does it not use the EABI, > but it hasn't had support for any core added since ARMv5 (and ARMv6 was > announced in 2002)! What do you mean exactly? The port works fine on ARMv7. > I therefore propose that we consider this port for deprecation. We have a port to VxWorks 7, which is EABI/AAPCS, ready to be contributed. -- Eric Botcazou
On 16/07/17 10:21, Eric Botcazou wrote: >> The port is also *very* out-of-date. Not only does it not use the EABI, >> but it hasn't had support for any core added since ARMv5 (and ARMv6 was >> announced in 2002)! > > What do you mean exactly? The port works fine on ARMv7. What I said. looking at the contents of vxworks.h I see: #define CC1_SPEC \ "%{tstrongarm:-mlittle-endian -mcpu=strongarm ; \ t4: -mlittle-endian -march=armv4 ; \ t4be: -mbig-endian -march=armv4 ; \ t4t: -mthumb -mthumb-interwork -mlittle-endian -march=armv4t ; \ t4tbe: -mthumb -mthumb-interwork -mbig-endian -march=armv4t ; \ t5: -mlittle-endian -march=armv5 ; \ t5be: -mbig-endian -march=armv5 ; \ t5t: -mthumb -mthumb-interwork -mlittle-endian -march=armv5 ; \ t5tbe: -mthumb -mthumb-interwork -mbig-endian -march=armv5 ; \ txscale: -mlittle-endian -mcpu=xscale ; \ txscalebe: -mbig-endian -mcpu=xscale ; \ : -march=armv4}" Nothing in that list post-dates armv5t, and many of the mentioned target architectures are under threat of deprecation in GCC, in addition to the old ABI (in particular armv5 is a nonsense architecture - it should be armv5t). Now maybe you've changed the way all this works but there's not much evidence of that in the ARM backend. I also don't see any evidence of this port being tested from a search of gcc-testresults. I also can't see how ARMv7 would work big-endian with the old ABI since there's no way of generating BE8 format images without at least some features from the new ABI (mapping symbols, forcing --be8 through to the linker, etc). So "works fine" would appear to have quite a narrow definition. > >> I therefore propose that we consider this port for deprecation. > > We have a port to VxWorks 7, which is EABI/AAPCS, ready to be contributed. > That's good news. Does that mean we'll be able to drop the old stuff though? I'd really like to make progress towards removing the old ABI support from GCC. Note that considering a port for deprecation is only the first step. It does not mean that it has been deprecated. Sometimes the only way to find out if a port really is wanted is to make such a threat... R.
> What I said. looking at the contents of vxworks.h I see: > > #define CC1_SPEC \ > "%{tstrongarm:-mlittle-endian -mcpu=strongarm ; \ > t4: -mlittle-endian -march=armv4 ; \ > t4be: -mbig-endian -march=armv4 ; \ > t4t: -mthumb -mthumb-interwork -mlittle-endian -march=armv4t ; \ > t4tbe: -mthumb -mthumb-interwork -mbig-endian -march=armv4t ; \ > t5: -mlittle-endian -march=armv5 ; \ > t5be: -mbig-endian -march=armv5 ; \ > t5t: -mthumb -mthumb-interwork -mlittle-endian -march=armv5 ; \ > t5tbe: -mthumb -mthumb-interwork -mbig-endian -march=armv5 ; \ > txscale: -mlittle-endian -mcpu=xscale ; \ > txscalebe: -mbig-endian -mcpu=xscale ; \ > > : -march=armv4}" > > Nothing in that list post-dates armv5t, and many of the mentioned target > architectures are under threat of deprecation in GCC, in addition to the > old ABI (in particular armv5 is a nonsense architecture - it should be > armv5t). OK, we have indeed changed the last one locally to -march=armv7-a. > I also can't see how ARMv7 would work big-endian with the old ABI since > there's no way of generating BE8 format images without at least some > features from the new ABI (mapping symbols, forcing --be8 through to the > linker, etc). So "works fine" would appear to have quite a narrow > definition. Yes, VxWorks certainly doesn't support all the combinations. > That's good news. Does that mean we'll be able to drop the old stuff > though? I'd really like to make progress towards removing the old ABI > support from GCC. Yes, I'd think so, but Olivier knows better. > Note that considering a port for deprecation is only the first step. It > does not mean that it has been deprecated. Sometimes the only way to > find out if a port really is wanted is to make such a threat... No disagreement. ;-) -- Eric Botcazou
Hi Richard, (back from a few days away) > On Jul 17, 2017, at 12:01 , Eric Botcazou <ebotcazou@adacore.com> wrote: > >> That's good news. Does that mean we'll be able to drop the old stuff >> though? I'd really like to make progress towards removing the old ABI >> support from GCC. > > Yes, I'd think so, but Olivier knows better. > >> Note that considering a port for deprecation is only the first step. It >> does not mean that it has been deprecated. Sometimes the only way to >> find out if a port really is wanted is to make such a threat... > > No disagreement. ;-) In this instance, no doubt we want to keep the port in. As I mentioned off-list, the port is still very active from our (AdaCore) perspective, I have just recently been enlisted as maintainer and plan to contribute significant updates. Part of that is support for VxWorks 7, which has switched to the new ABI. Regarding removal of old ABI support, which release were you targeting ? On the VxWorks front, where we adapt to what the system toolchains do, it will mean dropping support for VxWorks versions prior to 7, which is not so old - couple of years I think. Not the end of the world, but an extra release cycle can make a difference. Is VxWorks alone in this category ? Olivier
On 25/07/17 11:31, Olivier Hainque wrote: > Hi Richard, > > (back from a few days away) > >> On Jul 17, 2017, at 12:01 , Eric Botcazou <ebotcazou@adacore.com> wrote: >> >>> That's good news. Does that mean we'll be able to drop the old stuff >>> though? I'd really like to make progress towards removing the old ABI >>> support from GCC. >> >> Yes, I'd think so, but Olivier knows better. >> >>> Note that considering a port for deprecation is only the first step. It >>> does not mean that it has been deprecated. Sometimes the only way to >>> find out if a port really is wanted is to make such a threat... >> >> No disagreement. ;-) > > In this instance, no doubt we want to keep the port in. As I mentioned > off-list, the port is still very active from our (AdaCore) perspective, > I have just recently been enlisted as maintainer and plan to contribute > significant updates. > > Part of that is support for VxWorks 7, which has switched to the new > ABI. > > Regarding removal of old ABI support, which release were you > targeting ? > > On the VxWorks front, where we adapt to what the system toolchains > do, it will mean dropping support for VxWorks versions prior to 7, > which is not so old - couple of years I think. Not the end of the > world, but an extra release cycle can make a difference. > > Is VxWorks alone in this category ? Pretty close, I think. The only other ARM port using the old ABI that I'm aware of is NetBSD. That doesn't use GCC as it's default compiler these days and even there an EABI port is in use (I suspect Clang requires it). So until I became aware of the VXworks port using the old ABI, I thought there was only one remaining port - VXworks makes that 2 but both seem to have a transition plan of sorts. I think deprecating in gcc-8 with removal in GCC-9 is probably viable on that basis, so that's my opening bid. Given that gcc-8 will have a 2-year support window that means support for the old ABI through to ~2020, at which point v2 of the EABI will itself be 15 years old. R. > > Olivier > > > > >
Hi Richard, > On Jul 31, 2017, at 11:58 , Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote: > >> Regarding removal of old ABI support, which release were you >> targeting ? >> >> On the VxWorks front, where we adapt to what the system toolchains >> do, it will mean dropping support for VxWorks versions prior to 7, >> which is not so old - couple of years I think. Not the end of the >> world, but an extra release cycle can make a difference. >> >> Is VxWorks alone in this category ? > > Pretty close, I think. The only other ARM port using the old ABI that > I'm aware of is NetBSD. That doesn't use GCC as it's default compiler > these days and even there an EABI port is in use (I suspect Clang > requires it). > > So until I became aware of the VXworks port using the old ABI, I thought > there was only one remaining port - VXworks makes that 2 but both seem > to have a transition plan of sorts. > I think deprecating in gcc-8 with removal in GCC-9 is probably viable on > that basis, so that's my opening bid. Given that gcc-8 will have a > 2-year support window that means support for the old ABI through to > ~2020, at which point v2 of the EABI will itself be 15 years old. I see, thanks for sharing the plan. For VxWorks, it's really a matter of how long do we want to support versions prior to the most recent one today (VxWorks 7). Vx7 is only two years old, so dropping support in gcc-8 would have been pretty delicate. A year later seems like a fair compromise at this stage. Updating toolchains is usually an involved process, so people switching to gcc-8 would typically only do so months (roughly a year maybe) after it's out. It then seems possible that people really willing to switch toolchains after that might also consider moving to VxWorks >= 7 if not already done. We'll see. Regarding the port evolution, I'm about to post a few updates. A couple of these call for an ARM maintainer approval I think (e.g. addition of a _clear_cache variant to lib1funcs.S). I'll cc you on these specifically. Thanks for your feedback :) With Kind Regards, Olivier
diff --git a/gcc/config/arm/vxworks.h b/gcc/config/arm/vxworks.h index 9af37c7..f20324f 100644 --- a/gcc/config/arm/vxworks.h +++ b/gcc/config/arm/vxworks.h @@ -117,3 +117,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see /* This platform supports the probing method of stack checking (RTP mode). 8K is reserved in the stack to propagate exceptions in case of overflow. */ #define STACK_CHECK_PROTECT 8192 + +/* Unless overridded by the target options, the default is little-endian. */ +#define TARGET_ENDIAN_DEFAULT 0