[RFC PATCH 0/4] Enable Clang's Source-based Code Coverage and MC/DC for x86-64

Peter Zijlstra peterz at infradead.org
Wed Oct 15 02:21:45 PDT 2025


On Wed, Oct 15, 2025 at 08:26:50AM +0000, Chuck Wolber wrote:

> > I'm thinking I'm going to NAK this based on the fact that I'm not
> > interested in playing file based games. As long as this thing doesn't
> > honour noinstr I don't want this near x86.
> 
> I am working on a noinstr patchset that will precede this pachset. As it turns
> out there are several areas of the kernel (128 that I have found so far) that
> are missing the noinstr attribute macro.
> 
> Example:
> 
> kernel/locking/lockdep.c:
> 	void noinstr lockdep_hardirqs_off(unsigned long ip)
> include/linux/irqflags.h:
> 	static inline void lockdep_hardirqs_off(unsigned long ip) { }
> 
> The latter version is intended to be optimized out if the kernel is not
> configured to use this feature. However when the kernel is instrumented for
> profiling, the stub is not optimized out and ends up in the .text section
> rather than the .noinstr.text section.

Typically we switch to __always_inline when this happens. Ideally
though, compilers should strive to not be stupid and instrument dead
code to the point where DCE will fail.

> > And we have kcov support, and gcov and now llvm-cov, surely 3 coverage
> > solutions is like 2 too many?
> 
> Optimization makes it nearly impossible to correlate GCov results back to
> actual lines of source. llvm-cov instruments at the AST level which enables
> precise mapping back to source code regardless of optimization level.
> 
> 
> A detailed rundown on this issue can be found here[1], with the most relevant
> excerpt reproduced here:

Yes read and understand this, but that doesn't mean you have to have 3
different kernel interfaces for all of this, right?



More information about the linux-um mailing list