Re: git: 43e8849bc294 - main - conf: Enable BTI checking in the arm64 kernel
Date: Fri, 30 Aug 2024 15:35:03 UTC
On 8/30/24 04:55, Andrew Turner wrote: > > >> On 29 Aug 2024, at 17:02, Jessica Clarke <jrtc27@freebsd.org> wrote: >> >> On 21 Aug 2024, at 15:28, John Baldwin <jhb@FreeBSD.org> wrote: >>> >>> On 8/20/24 05:02, Andrew Turner wrote: >>>> The branch main has been updated by andrew: >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=43e8849bc29414036ccaef7788de95a07ad32ab5 >>>> commit 43e8849bc29414036ccaef7788de95a07ad32ab5 >>>> Author: Andrew Turner <andrew@FreeBSD.org> >>>> AuthorDate: 2024-08-19 12:59:49 +0000 >>>> Commit: Andrew Turner <andrew@FreeBSD.org> >>>> CommitDate: 2024-08-20 08:49:15 +0000 >>>> conf: Enable BTI checking in the arm64 kernel >>>> To ensure new code has BTI support make it an error to not have the >>>> BTI ELF note when linking the kernel and kernel modules. >>>> Reviewed by: kib, emaste >>>> Sponsored by: Arm Ltd >>>> Differential Revision: https://reviews.freebsd.org/D45469 >>> >>> This has broken two of the GitHub CI actions using clang 12 and clang 13. >>> Please fix this to be conditional on a supported linker version (or perhaps >>> add a new linker feature to bsd.linker.mk). >> >> This is still broken. If it’s not fixed promptly I will just revert >> this change; we can’t leave CI broken, especially when it gets used to >> test GitHub PRs. Please stop breaking building with older toolchains, >> this isn’t the first time it’s happened. > > See https://github.com/freebsd/freebsd-src/pull/1393 and https://github.com/freebsd/freebsd-src/pull/1399 I do think we probably want to flesh out a bit more what kind of policy we want for the range of compiler versions to support. E.g. in the GDB project the policy is something like "will not use a version of C++ newer than a compiler from 10 years ago" (IIRC). There they will also look back to whatever LTS distros are active and what is the newest compiler that can be installed on those LTS via the equivalent of ports. Traditionally we used to only support compiling FreeBSD N on FreeBSD N-1 (though we have often supported older versions of FreeBSD). However, we now also support cross-compiling from Linux and macOS, so we probably want to widen the support base a bit. I would say a first stab perhaps is that main and any supported stable and release branches should be buildable on a host running any of those versions. That is, FreeBSD 13 is still supported so we should keep main building on it directly without requiring a jump to FreeBSD 14 first. Once 13 EOLs then we can stop supporting 13, and that would gives folks on 13 a way to step up to the supported version of 14 at the time of the EOL. That said, presuambly fairly recent versions of LLVM (and GCC for that matter) will be available in ports for supported versions, so that doesn't necessarily require a very wide range of supported compiler versions. Supporting the "native" compiler on those releases would be a nice goal that I think is probably achievable with minimal effort. Today our oldest supported release is 14.0 which shipped with clang 16, and 13.3 shipped with clang 17. Both of those are quite a bit newer than clang 12 that is current oldest version in CI. I have no idea what version range might be sensible for Linux and macOS. Presumably we'd want to settle on some range of ubuntu LTS versions and whatever is the newest version you can install on the oldest LTS as the minimum. clang 12 might have been used in 13.1 (not mentioned in the release notes, 13.0 used clang 11, 13.2 used clang 14) and 12.3 (12.4 used clang 13, 12.2 used clang 10, 12.3 didn't mention it). I know CHERI LLVM is still on LLVM 15 (though moving to LLVM 16 soon, but Morello LLVM is 14 still I think). libc++ is also making this more complicated as they are providing very little compatability at all. They've already ripped out support for GCC 14 I believe, so you can't build current libc++ with a released version of GCC or something crazy. -- John Baldwin