Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV
Segher Boessenkool <[email protected]> Thu, 18 Dec 2025 05:58:44 -0600
| Newsgroups | org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <aUPsdDY09Jzn3ILf@gate> |
Hi! On Thu, Dec 18, 2025 at 10:56:48AM +0100, Marco Elver wrote: > On Thu, 18 Dec 2025 at 10:51, Peter Zijlstra <[email protected]> wrote: > > On Sat, Dec 13, 2025 at 08:59:44AM +0900, Ard Biesheuvel wrote: > > > > > > After that I sat down and finally got around to implement the builtin > > > > that should solve this once and for all, regardless of where it's > > > > called: https://github.com/llvm/llvm-project/pull/172030 > > > > What this will allow us to do is to remove the > > > > "K[AC]SAN_SANITIZE_noinstr.o := n" lines from the Makefile, and purely > > > > rely on the noinstr attribute, even in the presence of explicit > > > > instrumentation calls. > > > > > > > > > > Excellent! Thanks for the quick fix. Happy to test and/or look into > > > the kernel side of this once this lands. > > > > Well, would not GCC need to grow the same thing and then we must wait > > until these versions are the minimum supported versions for sanitizer > > builds. > > > > I mean, the extension is nice, but I'm afraid we can't really use it > > until much later :/ > > Unfortunately, yes. But let's try to get the builtin into Clang and > GCC now (for the latter, need to Cc GCC folks to help). > > Then we wait for 5 years. :-) > > There's a possibility to try and backport it to stable Clang and GCC > versions, but it's a long stretch (extremely unlikely). We (GCC) do not generally want to do backport features; even for bugfixes the risk/reward ratio comes into the picture. It *can* be done if some feature is important enough of course. If you have to wonder or ask if your feature is important enough, it is not. The reason we do not want backports of feature is it increases maintenance cost a lot, and so, development costs as well. I guess LLVM has a similar policy, but I of course do not speak for them. You might have more success getting the stuff backported to some distro(s) you care about? Or get people to use newer compilers more quickly of course, "five years" before people have it is pretty ridiculous, two years is at the tail end of things already. Segher