| Message ID | 20250307175435.3089686-1-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xen: Update minimum toolchain requirements | expand |
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,
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
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
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
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
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(-) base-commit: ac29d63a0fa6a3ed98ecf86f95995811c301308f