All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <jgrall@amazon.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.15] xen: Bump the minimum version of GCC supported to 4.9 (5.1 on arm64)
Date: Mon, 8 Mar 2021 10:51:34 +0000	[thread overview]
Message-ID: <7fd07dc9-9c03-bb13-3907-c3c268a4e970@xen.org> (raw)
In-Reply-To: <1897022d-7591-3450-4e57-884a2860b13d@suse.com>



On 08/03/2021 08:09, Jan Beulich wrote:
> On 06.03.2021 22:41, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Compilers older than 4.8 have known codegen issues which can lead to
>> silent miscompilation:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>>
>> Furthermore, pre-4.9 GCC have known bugs (including things like
>> internal compiler errors on Arm) which would require workaround (I
>> haven't checked if we have any in Xen).
>>
>> The minimum version of GCC to build the hypervisor is now raised to 4.9.
>>
>> In addition to that, on arm64, GCC version >= 4.9 and < 5.1 have been
>> shown to emit memory references beyond the stack pointer, resulting in
>> memory corruption if an interrupt is taken after the stack pointer has
>> been adjusted but before the reference has been executed.
>>
>> Therefore, the minimum for arm64 is raised to 5.1.
> 
> I'm sure newer compiler versions also have bugs.

I don't doubt that...

> Therefore I'm not
> convinced using this as the primary reason for a bump is enough.
You also have to take into account the severity of the bug and possible 
workaround. The bug in 5.1 is severe *and* has no easy (to avoid saying 
possible) workaround.

> Plus what if critical to us bugs get found in, say, 5.x? Are we
> going to bump to 6.x then (and so on, until we allow only the most
> recent major version to be used)?

In the current situation we are claiming that all GCC versions from 
~2014 are supported.

However, in reality, there are an high number of chance that some of the 
version will not build Xen or worse miscompile it.

The former kind of bug is not a big deal because the user will notice it 
directly. However, the latter is highly critical because 1) They may 
only happen sporadically 2) compiler related bug is difficult to root cause.

So I think a smaller set of version is going to be better for the users 
and for us long term.

> 
> Additionally - partly related to your own reply regarding the CI
> failures - imo there needs to be an analysis of what older distros
> will no longer build (at all or by default).

Per the CI, this would be Ubuntu Trusty (and older), Centos 7 (and older)

Do you have any other in mind?

> We've been discussing
> to bump minimum tool chain versions for a long time. At least as
> far as I'm concerned, I didn't take on this job precisely because
> the code changes needed are relatively simple, but justification
> can (and apparently will) be rather complicated.
>
> Fundamentally, whatever kind of criteria we use to justify the
> bump now ought to be usable down the road by people justifying
> further bumps.
I see you mentioned about distros. Can you outline other criteria you 
have in mind?

> 
> Also - what about clang? Linux requires 10.0.1 as a minimum.

I don't know and I would rather focus on GCC first so we figure out a 
set of criterias...

> 
>> ---
>>
>> I don't have a strong opinion on the minimum version for GCC on x86.
>> So this is following Andrew's suggestion and the minimum from Linux.
>>
>> This patch is candidate to 4.15 and backport.
> 
> I think such a change needs to be proposed much earlier in a release
> cycle.

Possibly... At the same time, we don't want to release 4.15 and continue 
to say Xen on Arm64 can build fine with 4.9 and 5.0.

> 
>> --- a/README
>> +++ b/README
>> @@ -38,12 +38,15 @@ provided by your OS distributor:
>>       * GNU Make v3.80 or later
>>       * C compiler and linker:
>>         - For x86:
>> -        - GCC 4.1.2_20070115 or later
>> +        - GCC 4.9 or later
>>           - GNU Binutils 2.16.91.0.5 or later
> 
> I don't think it makes much sense to keep the binutils version this
> low, the more that I don't think we can really build (correctly)
> with this old a version anymore. Whatever the gcc version chosen, I
> think we want to pick a binutils version from about the same time
> frame.

Ok. Let's first agree on a GCC version and then we can decide on a 
binutils version.

> 
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -5,6 +5,19 @@
>>   #error Sorry, your compiler is too old/not recognized.
>>   #endif
>>   
>> +#if CONFIG_CC_IS_GCC
>> +# if CONFIG_GCC_VERSION < 40900
>> +/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
> 
> As per the bug report, the issue was determined to not be present
> in e.g. 4.3. Hence while such a bug may influence our choice of
> minimum version, I don't think it can reasonably be named here as
> the apparent only reason for the choice. Personally I don't think
> any justification should be put here.

Ok.

> 
>> +#  error Sorry, your version of GCC is too old - please use 4.9 or newer.
>> +# elif defined(CONFIG_ARM_64) && CONFIG_GCC_VERSION < 50100
>> +/*
>> + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
>> + * https://lore.kernel.org/r/20210107111841.GN1551@shell.armlinux.org.uk
>> + */
>> +#  error Sorry, your version of GCC is too old - please use 5.1 or newer.
> 
>  From the bug entry the fix looks to have been backported to 4.9,
> or at least some (important?) branches thereof.

It is not clear what's you are trying to point out. Mind clarifying?

> 
>> +# endif
>> +#endif
> 
> Instead of a completely new conditional, I think this wants to be
> combined with the existing one (the tail of which is visible in
> context above).

OK.

Cheers,

-- 
Julien Grall


  reply	other threads:[~2021-03-08 10:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-06 21:41 [PATCH for-4.15] xen: Bump the minimum version of GCC supported to 4.9 (5.1 on arm64) Julien Grall
2021-03-07 10:57 ` Roger Pau Monné
2021-03-07 12:37   ` Julien Grall
2021-03-08  8:09 ` Jan Beulich
2021-03-08 10:51   ` Julien Grall [this message]
2021-03-08 11:20     ` Jan Beulich
2021-03-08 20:22       ` Julien Grall
2021-03-09 11:20         ` Jan Beulich
2021-03-10 18:05           ` Julien Grall
2021-03-11  8:17             ` Jan Beulich
2021-03-11  9:31               ` Julien Grall
2021-03-11 11:43                 ` Jan Beulich
2021-03-08  9:49 ` Ian Jackson
2021-03-10 20:48 ` Stefano Stabellini
     [not found] <161507188317.11025.6744028462008264481@c667a6b167f6>
2021-03-07 13:00 ` Julien Grall
2021-03-09  0:59   ` Stefano Stabellini
2021-03-09 10:05     ` Julien Grall
2021-03-09 10:32       ` Roger Pau Monné
2021-03-09 11:11         ` Anthony PERARD
2021-03-09 22:24         ` Stefano Stabellini
2021-03-10  7:52           ` Roger Pau Monné
2021-03-10 10:24             ` Zheng, Fam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7fd07dc9-9c03-bb13-3907-c3c268a4e970@xen.org \
    --to=julien@xen.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.