Re: [PATCH v5 23/23] xen/README: add compiler and binutils versions for RISC-V64

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/02/2024 10:58 pm, Julien Grall wrote:
> Hi Jan,
>
> On 27/02/2024 07:55, Jan Beulich wrote:
>> On 26.02.2024 18:39, Oleksii Kurochko wrote:
>>> This patch doesn't represent a strict lower bound for GCC and
>>> GNU Binutils; rather, these versions are specifically employed by
>>> the Xen RISC-V container and are anticipated to undergo continuous
>>> testing.
>>
>> Up and until that container would be updated to a newer gcc. I'm
>> afraid I view this as too weak a criteria,
>
> I disagree. We have to decide a limit at some point. It is sensible to
> say that we are only supporting what we can tests. AFAIK, this is what
> QEMU has been doing.
>
>> but I'm also not meaning to
>> stand in the way if somebody else wants to ack this patch in this form;
>> my bare minimum requirement is now met.
>>
>>> --- a/README
>>> +++ b/README
>>> @@ -48,6 +48,15 @@ provided by your OS distributor:
>>>         - For ARM 64-bit:
>>>           - GCC 5.1 or later
>>>           - GNU Binutils 2.24 or later
>>> +      - For RISC-V 64-bit:
>>> +        - GCC 12.2 or later
>>> +        - GNU Binutils 2.39 or later
>>> +        This doesn't represent a strict lower bound for GCC and GNU
>>> Binutils;
>>> +        rather, these versions are specifically employed by the Xen
>>> RISC-V
>>> +        container and are anticipated to undergo continuous testing.
>>
>> As per above, I think here it really needs saying "at the time of
>> writing"
>> or recording a concrete date. Furthermore I expect "these versions"
>> relates
>> to the specifically named versions and particularly _not_ to "or later":
>> With the criteria you apply, using later versions (or in fact any
>> version
>> other than the very specific ones used in the container) would be
>> similarly
>> untested. Much like x86 and Arm don't have the full range of permitted
>> tool chain versions continuously tested. Plus don't forget that
>> distros may
>> apply their own selection of patches on top of what they take from
>> upstream
>> (and they may also take random snapshots rather than released versions).
>
> TBH, I think this should be dropped from the README. With the wording,
> it implies that older GCC would work, but this is not a guarantee.
>
> The same for Arm, I suspect some revision of GCC below 5.1 that may
> work. But that's just convenience to list a lower limit.
>
> With the sentence dropped, I would be happy to ack this patch.
>
>>
>> IOW it is hard for me to see why RISC-V needs stronger restrictions here
>> than other architectures. It ought to be possible to determine a
>> baseline
>> version. Even if taking the desire to have "pause" available as a
>> requirement, gas (and presumably gld) 2.36.1 would already suffice.
>
> I think we want to bump it on Arm. There are zero reasons to try to
> keep a lower versions if nobody tests/use it in production.
>
> I would suggest to do the same on x86. What's the point of try to
> support Xen with a 15+ years old compiler?

There is a material cost to supporting ancient toolchains.  I'm
increasingly unwilling to keep paying.

I'm also bored of needing to support versions of binutils which don't
know the Virt instructions, which are approaching 2 decades old now.

There are very good reasons to move to GCC 5.1 minimum across the board,
because that gets us several features (__has_include(), asm goto and
_Generic()) which will make material improvements to our code.  And I'd
like to start using other bits of C11/gnu11.

The choice of minimum toolchains should definitely be per-arch, and
"this is the oldest one we regularly test" is an entirely fine reason to
set the minimum bar.

Furthermore, Linux has regularly been bumping minimum toolchain versions
due to code generation issues, and we'd be foolish not pay attention.

~Andrew