This is the mail archive of the
mailing list for the GCC project.
Re: [ARM, VXworks] Fix build
- From: Olivier Hainque <hainque at adacore dot com>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Olivier Hainque <hainque at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Eric Botcazou <ebotcazou at adacore dot com>, Arnaud Charlet <charlet at adacore dot com>, Joel Brobecker <brobecker at adacore dot com>
- Date: Tue, 1 Aug 2017 14:25:41 +0200
- Subject: Re: [ARM, VXworks] Fix build
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <5247673.EVQ205pMoZ@polaris> <firstname.lastname@example.org> <1676578.ADfKVQD1zE@polaris> <80D9D997-DE6B-4931-ACA2-E24C4DB0F969@adacore.com> <email@example.com>
> 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
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,