Re: [PATCH v2 0/4] Enable measuring the kernel's Source-based Code Coverage and MC/DC with Clang

[Nathan Chancellor <nathan@kernel.org>]

Hi Wentao,

I took this series for a spin on next-20241001 with LLVM 19.1.0 using a
distribution configuration tailored for a local development VM using
QEMU. You'll notice on the rebase for 6.12-rc1 but there is a small
conflict in kernel/Makefile due to commit 0e8b67982b48 ("mm: move
kernel/numa.c to mm/").

I initially did the build on one of my test machines which has 16
threads with 32GB of RAM and ld.lld got killed while linking vmlinux.o.
Is your comment in the MC/DC patch "more memory is consumed if larger
decisions are getting counted" relevant here or is that talking about
runtime memory on the target device? I assume the latter but I figured I
would make sure. If not, it might be worth a comment somewhere that this
can also require some heftier build resources possibly? If that is not
expected, I am happy to help look into why it is happening.

I was able to successfully build that same configuration and setup with
my primary workstation, which is much beefier. Unfortunately, the
resulting kernel did not boot with my usual VM testing setup. I will see
if I can narrow down a particular configuration option that causes this
tomorrow because I did a test with defconfig +
CONFIG_LLVM_COV_PROFILE_ALL and it booted fine. Perhaps some other
option that is not compatible with this? I'll follow up with more
information as I have it.

On the integration front, I think the -mm tree, run by Andrew Morton,
would probably be the best place to land this with Acks from the -tip
folks for the x86 bits? Once the issue above has been understood, I
think you can send v3 with any of the comments I made addressed and a
potential fix for the above issue if necessary directly to him, instead
of just on cc, so that it gets his attention. Other maintainers are free
to argue that it should go through their trees instead but I think it
would be good to decide on that sooner rather than later so this
patchset is not stuck in limbo.

Cheers,
Nathan