Re: [PATCH] xen: Update minimum toolchain requirements

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/03/2025 8:18 am, Jan Beulich wrote:
> On 07.03.2025 18:54, Andrew Cooper wrote:
>> GCC 4.1.2 is from 2007, and Binutils 2.16 is a similar vintage.  Clang 3.5 is
>> from 2014.  Supporting toolchains this old is a massive development and
>> testing burden.
>>
>> Set a minimum baseline of GCC 5.1 across the board, along with Binutils 2.25
>> which is the same age.  These were chosen *3 years ago* as Linux's minimum
>> requirements because even back then, they were ubiquitous in distros.
> I'm certainly fine with this bump, but my main earlier request remains: I'd
> like it to be clear up front what the criteria are going to be for future
> bumps. Imo what Linux does is at best a data point; we don't need to follow
> what they do.

I'm reluctant to try and put anything in writing, because it will just
make the arguments worse.

We can and may change the toolchain requirements at any point for any
reason, depending on the situation.

Retpolines for Spectre-v2 are the obvious example.  That reset the
compiler baseline to "bleeding edge plus secret patches" for all intents
and purposes.  Distros also backported those patches into their older
compilers.  Yes, we did eventually manage to make this conditional, but
that's not terribly relevant.

Here, I've proposed several concrete things which would be good to use,
and that we cannot because the baseline is too old.

And that's how it's always going to be.  We move forwards when there's a
good enough reason to, and the downsides are tolerable.


The Linux aspect is a datapoint, but it's an important one; it means
that anyone building Linux (i.e. ~all of our target audience) already
has these tools.  That is "there's no real downside" put a little less
bluntly.
>>  Choose
>> Clang/LLVM 11 as a baseline for similar reasons; the Linux commit making this
>> change two years ago cites a laudry list of code generation bugs.
> I'm less happy about this one. It'll mean I now also need to arrange for
> building Clang on my own, which so far I was quite happy to be able to avoid.

Prebuilt binaries are available. 
https://github.com/ClangBuiltLinux/tc-build has instructions for local
builds, and a script which tries to help out with what to turn off.

Everything in GitlabCI is available locally from within xen.git itself
via automation/scripts/containerize.  There's also FreeBSD testing
available via CirrusCI.

The reason for going with Clang/LLVM 11 is because it's a known entity,
and is already 5 years old, and it's necessary if we want to use
asm_goto, which was one of the key justifications for making the jump.

> Tangentially, as also mentioned during earlier discussions, it would also be
> nice to have an understanding what other basic platform components (e.g.
> coreutils) are required to fulfill certain minimal requirements. While
> putting in place a custom toolchain is (to me at least) relatively easy,
> doing the same for other base platform software isn't. For some of the very
> old systems I try to keep testing Xen on, extra requirements there may mean
> that building Xen there isn't going to be possible anymore. Which in turn
> may mean running the toolstack (built on a newer distro) there may also not
> be possible anymore. Which would, perhaps severely, limit the usefulness of
> such testing attempts.

As before, I don't expect us to change things unless there is a good
reason to.

That said, a few things come to mind:

We need to drop Python2 support at some point.  It's substantially EOL,
and we're about to drop the last test environment that has it (IIRC).

Make 3.80 is also ancient, and I'm still irritated at not being able to
use $(abspath) to fix XEN_ROOT.  We have an insane amount of ../../../
embedded in our binaries and debug symbols because of how XEN_ROOT is
constructed.

~Andrew