Re: [ARM, VXworks] Fix build

[Olivier Hainque <hainque at adacore dot com>]

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