> 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