Issues compling and linking in one step

[broonie]

When attempting to build the arm64 selftests with LLVM:

make -C tools/testing/selftests TARGETS="arm64 ftrace kvm perf_events rseq rtc" ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- \
        LLVM=1 install INSTALL_PATH=/tmp/kselftest-install

clang gets upset:

make[2]: Entering directory '/home/broonie/git/linux/tools/testing/selftests/arm64/signal'
clang --target=aarch64-none-linux-gnu -fintegrated-as -Wall -O2 -g -I/home/broonie/git/linux/tools/testing/selftests/ -isystem /home/broonie/git/linux/usr/include -D_GNU_SOURCE -std=gnu99 -I.  test_signals.c test_signals_utils.c testcases/testcases.c signals.S testcases/fake_sigreturn_bad_magic.c test_signals.h test_signals_utils.h testcases/testcases.h -o testcases/fake_sigreturn_bad_magic
clang: error: cannot specify -o when generating multiple output files
make[2]: *** [Makefile:27: testcases/fake_sigreturn_bad_magic] Error 1
make[2]: Leaving directory '/home/broonie/git/linux/tools/testing/selftests

which is happening because the Makefile uses a dependency rule which includes the headers as deps to ensure appropriate autobuilding but also results in the headers being passed into clang as targets:

$(PROGS): test_signals.c test_signals_utils.c testcases/testcases.c signals.S $$@.c test_signals.h test_signals_utils.h testcases/testcases.h
    $(CC) $(CFLAGS) $^ -o $@

This is not the most elegant thing but has an obvious meaning (the header files should build as C files), is accepted by GCC and while this Makefile does not fill me with joy it does seem like the compiler should work here.

(there are other errors currently with the arm64 selftests but I've got patches for the rest already).

[nickdesaulniers]

reminds me of: commit 03cab65a07e0 ("selftests/futex: fix build for clang")

[broonie]

Yes, that's basically the issue and roughly the fix I have - I mostly filed this because it seems like something that'll come up again and something that LLVM really ought to cope with. Still have another build issue in the signal tests but I'll send what I've got tomorrow either fixing or reporting that.

The problem here seems architecture neutral, just passing a header on the command line ought to trigger it, and I'm mainly reporting it because it looks like something clang should cope with.

[broonie]

Upstream shouldn't be affected once https://lore.kernel.org/r/20230111-arm64-kselftest-clang-v1-3-89c69d377727@kernel.org is applied. Like I say it still feels like something the compiler should cope with though.