On Sat, 3 May 2025 at 01:25, Shuah Khan skhan@linuxfoundation.org wrote:
When make finds the source tree unclean, it prints a message to run "make ARCH=x86_64 mrproper" message using the ARCH from the command line. The ARCH specified in the command line could be different from the ARCH of the existing build in the source tree.
This could cause problems in regular kernel build and kunit workflows.
Regular workflow:
Build x86_64 kernel $ make ARCH=x86_64
Try building another arch kernel out of tree with O= $ make ARCH=um O=/linux/build
kbuild detects source tree is unclean
*** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /linux/linux_srcdir
Clean source tree as suggested by kbuild $ make ARCH=um mrproper
Source clean appears to be clean, but it leaves behind generated header files under arch/x86 arch/x86/realmode/rm/pasyms.h
A subsequent x86_64e build fails with "undefined symbol sev_es_trampoline_start referenced ..."
kunit workflow runs into this issue:
Build x86_64 kernel
Run kunit tests: it tries to build for user specified ARCH or uml as default: $ ./tools/testing/kunit/kunit.py run
kbuild detects unclean source tree
*** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /linux/linux_6.15
Clean source tree as suggested by kbuild $ make ARCH=um mrproper
Source clean appears to be clean, but it leaves behind generated header files under arch/x86
The problem shows when user tries to run tests on ARCH=x86_64:
$ ./tools/testing/kunit/kunit.py run ARCH=x86_64 "undefined symbol sev_es_trampoline_start referenced ..."Build trips on arch/x86/realmode/rm/pasyms.h left behind by a prior x86_64 build.
Problems related to partially cleaned source tree are hard to debug. Change Makefile to unclean source logic to use ARCH from compile.h UTS_MACHINE string. With this change kbuild prints:
$ ./tools/testing/kunit/kunit.py run
*** The source tree is not clean, please run 'make ARCH=x86_64 mrproper' *** in /linux/linux_6.15
Signed-off-by: Shuah Khan skhan@linuxfoundation.org
Thanks very much! This is much better, and has given the right message on all of the architecture in-/out-of-tree build combinations I've thrown at it.
Reviewed-by: David Gow <davidgow@google.com<
Cheers, -- David