Re: [ARM, VXworks] Fix build

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

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.