[ARM,VXworks] Fix build

Message ID b88a98fa-b4de-9e76-c5a9-9201feb3b4d0@arm.com
State New
Headers show

Commit Message

Richard Earnshaw (lists) July 13, 2017, 10:03 a.m.
My patch last week to address selection of be8 linking mode broke the
build for vxworks.  It turns out that this port is one of the few
remaining that is still not based on the EABI/AAPCS.

This patch fixes the build, but I've not really tested it beyond
building the core compiler binaries.  Building a workable compiler
entails downloading a load of vxworks stuff that I'm not sure where to find.

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)!

I therefore propose that we consider this port for deprecation.

	* config/arm/vxworks.h (TARGET_ENDIAN_DEFAULT): Define.

Comments

Eric Botcazou July 16, 2017, 9:21 a.m. | #1
> 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
Richard Earnshaw (lists) July 17, 2017, 9:39 a.m. | #2
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.
Eric Botcazou July 17, 2017, 10:01 a.m. | #3
> 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
Olivier Hainque July 25, 2017, 10:31 a.m. | #4
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
Richard Earnshaw (lists) July 31, 2017, 9:58 a.m. | #5
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

> 

> 

> 

> 

>
Olivier Hainque Aug. 1, 2017, 12:25 p.m. | #6
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

Patch

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