On Fri, Jul 25, 2025 at 12:36:34PM +0200, Thomas Weißschuh wrote:
FWIW some architectures use GNU ld implicitly with clang because they also link through $(CC) but do not use --ld-path. One example is UML, where the vDSO and vmlinux are linked this way. But linking vmlinux of UML with ld.lld will require changes to at least the linker script. Something for the ClangBuiltLinux TODO? There were more examples, but I don't remember them right now.
Yes, I believe this is the issue we had for tracking using ld.lld with UML: https://github.com/ClangBuiltLinux/linux/issues/1715
I had not considered that it could be a linker script handling difference. I will have to look into that soon.
Longterm --ld-path should probably be added to the global KBUILD_CFLAGS, too.
'--ld-path' is only relevant when the linking phase is run by the compiler, which is not really normal for the primary kernel build, as calling the linker directly with $(LD) is preferred. Doing that would break the build because of -Werror=unused-command-line-argument, which is needed to make cc-option work correctly.
$ echo 'int main(void) { return 0; }' | /usr/bin/clang --ld-path=/usr/bin/ld.lld -c -o /dev/null -x c - clang: warning: argument unused during compilation: '--ld-path=/usr/bin/ld.lld' [-Wunused-command-line-argument]
$ echo 'int main(void) { return 0; }' | /usr/bin/clang --ld-path=/usr/bin/ld.lld -o /dev/null -x c -
No, it isn't respected. On the other hand I didn't yet run into any issues. Do we want to fix it proactively?
No, I think it is fine to just leave it as is and fix it if it comes up in the future, as I believe getting LLVM_IAS=1 working for sparc64 is the next major focus of the whole LLVM sparc endeavour.
Cheers, Nathan