Re: git: 43e8849bc294 - main - conf: Enable BTI checking in the arm64 kernel
- In reply to: John Baldwin : "Re: git: 43e8849bc294 - main - conf: Enable BTI checking in the arm64 kernel"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 31 Aug 2024 15:56:07 UTC
On Fri, Aug 30, 2024 at 9:35 AM John Baldwin <jhb@freebsd.org> wrote: > 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. > QEMU does similar things. > 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. > Recent history has been such that all supported branches can jump to head. It's been more like N-2 or N-3 (12 -> head still works last I tried it, but it's likely to break at any random llvm import and we've had once since I (accidentally) tried it). In general, it's good policy if we can do it. In the earlier days of the project, there was considerably more API churn that required more compatibility shims than we need these days. It's usually just a matter of having a new enough C++ compiler for the latest language features used by llvm. I think the last breakage I looked into was like that (11 didn't have a new enough llvm for 14-current). As you note, we have ports/pkgs that can do that, but only if we keep the older recently not supported branches final packages around... Also to clarify one point: It's only the last supported release on the stable branch or newer that can jump to -current, not any point since the branch (though it often works, we dropped that effort some time ago when its main champion moved on from contributing to the FreeBSD project). I think stable-11 got a 'final' llvm update late in the branche's life because we hadn't had a release in too long, but I may be misremembering. But having said all that, I agree: this isn't going to widen things all that much. 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). > That gets back to the question of 'tip of the branch' or 'from the branch point'. I think that we should require only tip of branch (so we don't gate using new compiler features in head for something we shipped in 13.0), but encourage people to put the API compat shims into the build library for a wider range (since they will likely also be needed for Linux/MacOS too, independent of compiler version). > 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. > Upstream will, perhaps sadly, drive a lot of our policy in this area. When upstream de-orbits support for something, it's hard for us to keep maintaining it and keep updating to upstream without some kind of compelling need. Though I recently spend a fair amount of time coming up with a fairly minimal tweak to our cdefs.h that makes it more compatible with the crazy things that libc++ does to still support compiling older C++ standards. Which brings up another possible issue. We don't support building FreeBSD, itself, with anything but a fairly up-to-date wrt standards compiler. However, we support building binaries from sources that compile with C89 and newer, and C++98 and newer (though really this is likely C++11 for most things, given the upstream de-orbiting of support for older standard binaries). We may need to carefully call this out as well... The older C++ standards don't matter too much (most of the C++ plorts actually want the newer C++), but there's still a lot of packages that compile with a strict C89 feature set that break in subtle ways when we break support for that... Warner