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.  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.

This will allow us to retire a lot of compatiblity logic, and start using new
features previously unavailable because of no viable compatibility option.

Merge the ARM 32bit and 64bit sections now they're the same.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>

PPC doesn't have a minimum set stated yet, but CI tests GCC 10 from Debian 11.

This will require dropping some containers from CI.  CentOS 7 notably.

In terms of specific new features, I'm interested in:

 * __has_include() to remove the asm-generic makefile tangle
 * asm goto (), to remove .fixup and code generation for error handling.

and these too, but will require MISRA adjustments:

 * _Generic() to make properly const-preserving wrappers
 * Updating our -std to gnu11, which drops further compatibility logic

When the arguments die down, I'll add a hunk to CHANGELOG.md as this is very
significant.
---
 README | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/README b/README
index 9d9c6fc324c6..be90be3910d4 100644
--- a/README
+++ b/README
@@ -38,16 +38,13 @@ provided by your OS distributor:
     * GNU Make v3.80 or later
     * C compiler and linker:
       - For x86:
-        - GCC 4.1.2_20070115 or later
-        - GNU Binutils 2.16.91.0.5 or later
+        - GCC 5.1 or later
+        - GNU Binutils 2.25 or later
         or
-        - Clang/LLVM 3.5 or later
-      - For ARM 32-bit:
-        - GCC 4.9 or later
-        - GNU Binutils 2.24 or later
-      - For ARM 64-bit:
+        - Clang/LLVM 11 or later
+      - For ARM:
         - GCC 5.1 or later
-        - GNU Binutils 2.24 or later
+        - GNU Binutils 2.25 or later
       - For RISC-V 64-bit:
         - GCC 12.2 or later
         - GNU Binutils 2.39 or later

base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f
-- 
2.39.5

On Fri, Mar 07, 2025 at 05:54:35PM +0000, 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.  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.
> 
> This will allow us to retire a lot of compatiblity logic, and start using new
> features previously unavailable because of no viable compatibility option.
> 
> Merge the ARM 32bit and 64bit sections now they're the same.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

IIRC Ld in LLVM 11 should be capable of linking Xen.  I think the
first LLVM release with an LD capable of linking Xen was version 6 or
7.

Thanks, Roger.

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.

>  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.

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.

Jan

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

On 2025-03-07 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.  
> 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.
> 
> This will allow us to retire a lot of compatiblity logic, and start 
> using new
> features previously unavailable because of no viable compatibility 
> option.
> 
> Merge the ARM 32bit and 64bit sections now they're the same.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
> CC: Bertrand Marquis <bertrand.marquis@arm.com>
> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> CC: Shawn Anastasio <sanastasio@raptorengineering.com>
> 
> PPC doesn't have a minimum set stated yet, but CI tests GCC 10 from 
> Debian 11.
> 
> This will require dropping some containers from CI.  CentOS 7 notably.
> 
> In terms of specific new features, I'm interested in:
> 
>  * __has_include() to remove the asm-generic makefile tangle
>  * asm goto (), to remove .fixup and code generation for error 
> handling.
> 
> and these too, but will require MISRA adjustments:
> 
>  * _Generic() to make properly const-preserving wrappers

Perhaps stating something that is already well-known, but this 
effectively means moving from MISRA C:2012 Amendment 2 as a target to, 
at least, MISRA C:2012 Amendment 3, as that version contains rules in 
series 23 for _Generic.

>  * Updating our -std to gnu11, which drops further compatibility logic
> 
> When the arguments die down, I'll add a hunk to CHANGELOG.md as this is 
> very
> significant.
> ---
>  README | 13 +++++--------
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/README b/README
> index 9d9c6fc324c6..be90be3910d4 100644
> --- a/README
> +++ b/README
> @@ -38,16 +38,13 @@ provided by your OS distributor:
>      * GNU Make v3.80 or later
>      * C compiler and linker:
>        - For x86:
> -        - GCC 4.1.2_20070115 or later
> -        - GNU Binutils 2.16.91.0.5 or later
> +        - GCC 5.1 or later
> +        - GNU Binutils 2.25 or later
>          or
> -        - Clang/LLVM 3.5 or later
> -      - For ARM 32-bit:
> -        - GCC 4.9 or later
> -        - GNU Binutils 2.24 or later
> -      - For ARM 64-bit:
> +        - Clang/LLVM 11 or later
> +      - For ARM:
>          - GCC 5.1 or later
> -        - GNU Binutils 2.24 or later
> +        - GNU Binutils 2.25 or later
>        - For RISC-V 64-bit:
>          - GCC 12.2 or later
>          - GNU Binutils 2.39 or later
> 
> base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

On 07/03/2025 6:22 pm, Nicola Vetrini wrote:
> On 2025-03-07 18:54, Andrew Cooper wrote:
>> and these too, but will require MISRA adjustments:
>>
>>  * _Generic() to make properly const-preserving wrappers
>
> Perhaps stating something that is already well-known, but this
> effectively means moving from MISRA C:2012 Amendment 2 as a target to,
> at least, MISRA C:2012 Amendment 3, as that version contains rules in
> series 23 for _Generic.

Yes, I was expecting something along these lines.  It's also why I don't
suggest we start using it immediately.  (There's *loads* of non-MISRA
related work to do when these changes get accepted.)


Part of the justification for doing the MISRA work upstream was so it
could stay "clean" on an ongoing basis.  The corollary to this is that
our choice of MISRA standard needs to adapt as upstream Xen changes.


Do you have any insight on how disruptive this would be?  I presume it's
not as simple as running sed over our docs and Eclair config, but I also
don't imagine it's a giant task either.

~Andrew

On 2025-03-07 19:30, Andrew Cooper wrote:
> On 07/03/2025 6:22 pm, Nicola Vetrini wrote:
>> On 2025-03-07 18:54, Andrew Cooper wrote:
>>> and these too, but will require MISRA adjustments:
>>> 
>>>  * _Generic() to make properly const-preserving wrappers
>> 
>> Perhaps stating something that is already well-known, but this
>> effectively means moving from MISRA C:2012 Amendment 2 as a target to,
>> at least, MISRA C:2012 Amendment 3, as that version contains rules in
>> series 23 for _Generic.
> 
> Yes, I was expecting something along these lines.  It's also why I 
> don't
> suggest we start using it immediately.  (There's *loads* of non-MISRA
> related work to do when these changes get accepted.)
> 
> 
> Part of the justification for doing the MISRA work upstream was so it
> could stay "clean" on an ongoing basis.  The corollary to this is that
> our choice of MISRA standard needs to adapt as upstream Xen changes.
> 
> 
> Do you have any insight on how disruptive this would be?  I presume 
> it's
> not as simple as running sed over our docs and Eclair config, but I 
> also
> don't imagine it's a giant task either.
> 

Yes, indeed. I needs a global re-evaluation due to new rules being 
introduced (e.g. _Noreturn handling gets its own rules in Amendment 3) 
so those would need to be discussed in-depth, but the impact is probably 
not dramatic overall in terms of configuration changes, as most of the 
rules are unchanged.

> ~Andrew

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Hi,

On 07/03/2025 17: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.  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.
> 
> This will allow us to retire a lot of compatiblity logic, and start using new
> features previously unavailable because of no viable compatibility option.
> 
> Merge the ARM 32bit and 64bit sections now they're the same.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall