Re: [PATCH 3/3] CHANGELOG: Minimum toolchain requirements

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/03/2025 4:55 pm, Oleksii Kurochko wrote:
>
>
> On 3/27/25 4:45 PM, Andrew Cooper wrote:
>> On 21/03/2025 4:24 pm, Oleksii Kurochko wrote:
>>> On 3/20/25 4:59 PM, Andrew Cooper wrote:
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>>> CC: Michal Orzel <michal.orzel@xxxxxxx>
>>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>>> CC: Julien Grall <julien@xxxxxxx>
>>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>>> ---
>>>>  CHANGELOG.md | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>>> index 9a5919585d43..4e333e608a96 100644
>>>> --- a/CHANGELOG.md
>>>> +++ b/CHANGELOG.md
>>>> @@ -7,6 +7,9 @@ The format is based on [Keep a 
>>>> Changelog](https://keepachangelog.com/en/1.0.0/)
>>>>  ## [4.21.0 
>>>> UNRELEASED](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=staging)
>>>>  - TBD
>>>>  
>>>>  ### Changed
>>>> + - The minimum toolchain requirements have been increased to either:
>>>> +   - GCC 5.1 and Binutils 2.25, or
>>>> +   - Clang/LLVM 11
>>> I think we want here to specify for which architectures it was done as 
>>> RISC-V, for example, uses
>>> different versions:
>>>  - GCC 12.2 or later
>>>  - GNU Binutils 2.39 or later
>>> And for clang the version will be 17 as:
>>>   f873029386dd415cd9caa78f600a593d9570c9ae("[BOLT] Add minimal RISC-V 
>>> 64-bit support")
>>>   $ git tag --contains f873029386dd415cd9caa78f600a593d9570c9ae
>>>     llvmorg-17.0.0
>>>   ...
>>> I have some patch to build Xen RISC-V using clang-17 but I haven't sent to 
>>> upstream yet as I am not
>>> really sure that if we need (or why we need) clang support just from the 
>>> start.
>> The same reason why we got an almost-nothing build in CI first, and are
>> currently looking for a "hello world" message on boot.
>>
>> Keeping it working as you go is much easier than retrofitting at a later
>> point, and supporting more than 1 of any $THING (not just compilers) is
>> good to prevent accidental reliance on an implementation specific property.
>>
>> The only question is what version of Clang exists in Debian bookworm, as
>> that affects how easy/hard it is to add to CI.
>>
>> According to https://packages.debian.org/search?keywords=clang, bookworm
>> has Clang 14, while trixie has Clang 19.
>>
>> So, how hard a limit is Clang-17?  Is Clang-14 doable or not?
> I think it is pretty hard limit because:
> 1. I haven't checked all the extension but, for example, we required 'H' 
> extension and
>    the support for it was added in 16.0.0:
>    [f4c887c3a8406d85f4f942c8350f10026994f4d8("RISCV] Add H extension")
>    $ git tag --contains f4c887c3a8406d85f4f942c8350f10026994f4d8
>      llvmorg-16.0.0
>      ...
> 2. Minimal support for RISCV-64 was added in clang17:
>    f873029386dd415cd9caa78f600a593d9570c9ae("[BOLT] Add minimal RISC-V 64-bit 
> support")
>    $ git tag --contains f873029386dd415cd9caa78f600a593d9570c9ae
>      llvmorg-17.0.0
>      ...
> And, actually, the second one reason was the reason why I tried to build with 
> clang17 and suggests to use
> it as a baseline.

That's fine.  It means we can't use Debian bookworm for this purpose.

>
>> Alternatively, we could start adding some trixie containers.  We have
>> passed the toolchain freeze (was 15th March), so the build container
>> should be stable now, even if it isn't quite released yet.
> clang has nice script to add any version. I did that in the following way
> for bookworm docker container:
> +    DEPS=(
> +        # Clang
> +        wget
> +        gnupg
> +        ca-certificates
> +        lsb-release
> +        software-properties-common
> ...
> +    update-ca-certificates
> +
> +    wget -O - https://apt.llvm.org/llvm.sh | bash -s 17
> +    wget -O - https://apt.llvm.org/llvm.sh | bash -s 18
> +    wget -O - https://apt.llvm.org/llvm.sh | bash -s 19
> +    wget -O - https://apt.llvm.org/llvm.sh | bash -s 20
> +    # ln -s /usr/bin/clang-17 /usr/bin/clang

We used to do this.

It backfired spectacularly when rebuilding a container after versions of
clang had been dropped, and took out testing on the stable-* trees as a
consequence.

Therefore, we don't do this any more.  (Or at least, not in a container
marked for blocking failures.)

~Andrew