This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM, VXworks] Fix build


On 25/07/17 11:31, Olivier Hainque wrote:
> Hi Richard,
> 
> (back from a few days away)
> 
>> On Jul 17, 2017, at 12:01 , Eric Botcazou <ebotcazou@adacore.com> wrote:
>>
>>> 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. ;-)
> 
> In this instance, no doubt we want to keep the port in. As I mentioned
> off-list, the port is still very active from our (AdaCore) perspective,
> I have just recently been enlisted as maintainer and plan to contribute
> significant updates.
> 
> Part of that is support for VxWorks 7, which has switched to the new
> ABI.
> 
> 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.

R.

> 
> Olivier
> 
> 
> 
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]