[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

Patch hide | download patch | download mbox

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