Support CC=clang and LD=ld.lld #169
Conversation
|
cc @ColinIanKing , @dileks, @torvic9 |
nickdesaulniers
force-pushed
the
llvm_support
branch
from
8881c7b to
f36b182
Compare
|
Since the original bug report doesn't show the failure message, here's what it looks like without this patch, FWIW: |
|
Unless I'm mistaken (I haven't tested the patch yet), this does not work when the kernel binary is stripped. Arch for example strips by default. Grepping for the clang string is not beautiful and less than ideal, but it does the job too. |
|
nickdesaulniers
force-pushed
the
llvm_support
branch
from
f36b182 to
6dbc0b3
Compare
|
I guess my question to @scaronni and @evelikov would be: should I be checking the currently running kernel first, in preference to whatever we find in the kernel source dir? I guess I could be running an older kernel but trying to run dkms against newer kernel sources (or vice versa)...or is that not a supported use case of dkms? The kernel sources aren't necessarily the kernel I have booted; I'm not sure which dkms prefers, generally. |
Oops. Sorry, you're right. |
|
Mind you, despite my recent activity in the project I doubt my input carries much weight. That said: I think the current patch is good as-is. It uses the kernel in For reference, here is what my Arch box (using GCC 11) reports for the comment section: |
|
This does not work for systems with a bzImage, like RHEL based systems or Suse.. what about checking the |
|
I think the proposal of reading the |
|
Why not decide the priority between the binary and I installed How about:
? Would that catch all cases? Pseudo-code (greps should probably be double-checked): |
ghost
mentioned this pull request
@scaronni what do you mean? bzImage is a compressed artifact built from the vmlinux ELF image. ie. vmlinux is built first, then compressed, then a decompressor is prepended with
Which config, the one from the running kernel image or from the kernel sources? @flindeberg suggests checking from kernel sources. Is
Right, that's my question for the maintainers of dkms. I don't mind checking the .config file, but here's a theoretical case that could be broken:
I suspect DKMS has had to deal with the above scenarios, so I'd like to know how DKMS prefers to handle them. I think it's a good idea if we fail the check of Perhaps a revision to @flindeberg suggestion:
This ignore the running vmlinux and config and depends on what's in the kernel source directory as the sole source of truth. Thoughts? |
As long as the running kernel is ignored I'm happy, as that would allow me to have kernels compiled with different tool-chains installed and working DKMS support. |
The |
Would checking |
SGTM
What does |
|
Yes that does: |
|
Thinking out loud: Do we want "--use-clang" toggle in addition (or instead of) this MR? |
I'd say in addition to. You would definitely want detection of build tools when scripting updates of DKMS modules for all installed kernels. A common use-case is updating your Nvidia drivers (the DKMS-version), where I would preferably run the same command for each installed kernel and only change the kernel-argument between runs. |
Wonder what the ratio of Nvidia drivers vs everything else 😛 |
|
Wouldn't be easier to avoid autodetection and just add some configuration directives in Autodetection would be nice, but people which need to specify a compiler for a kernel are either distribution maintainers (so the appropriate configuration should already be in packaged |
There was a problem hiding this comment.
If you add the environment variables CC and LD at that point, $make_command will not be an empty string, and the following conditional expression will not work correctly.
# Use the generic make and make clean commands if not specified
[[ ! $make_command ]] && make_command="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build"
There was a problem hiding this comment.
diff --git a/dkms.in b/dkms.in
index 9c98a89..784831f 100644
--- a/dkms.in
+++ b/dkms.in
@@ -575,6 +575,20 @@ read_conf()
[[ ! $make_command ]] && make_command="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build"
[[ ! $clean ]] && clean="make -C $kernel_source_dir M=$dkms_tree/$module/$module_version/build clean"
+ if [[ -e $kernel_source_dir/vmlinux ]]; then
+ if cat $kernel_source_dir/.config | grep -q CONFIG_CC_IS_CLANG=y; then
+ make_command="${make_command} CC=clang"
+ elif readelf -p .comment $kernel_source_dir/vmlinux | grep -q clang; then
+ make_command="${make_command} CC=clang"
+ fi
+
+ if cat $kernel_source_dir/.config | grep -q CONFIG_LD_IS_LLD=y; then
+ make_command="${make_command} LD=ld.lld"
+ elif readelf -p .comment $kernel_source_dir/vmlinux | grep -q LLD; then
+ make_command="${make_command} LD=ld.lld"
+ fi
+ fi
+
# Set patch_array (including kernel specific patches)
count=0
for ((index=0; index < ${#PATCH[@]}; index++)); do
6dbc0b3 to
57dfce9
Compare
|
I've updated my commit to additionally check |
When building the Linux kernel, one may use `make LLVM=1` to set multiple flags, akin to `make CC=clang LD=ld.lld NM=llvm-nm ...` (see the link below for kernel docs explaining this further in detail). When building kernel modules, to ensure we're using the same toolchain as the underlying core kernel image, Kbuild will error if it's reinvoked with a toolchain that differs. This causes DKMS to fail, since it's not re-specifying the same compiler (or linker, etc). Check the .comment section of the vmlinux file in the Linux kernel source dir, and set CC= and LD= flags for make based on that. If vmlinux does not exist, grep .config for CONFIG_CC_IS_CLANG=y and CONFIG_LD_IS_LLD=y. Fixes: dkms-project#124 Fixes: ClangBuiltLinux/linux#1104 Link: https://docs.kernel.org/kbuild/llvm.html Suggested-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
nickdesaulniers
force-pushed
the
llvm_support
branch
from
57dfce9 to
6ddb091
Compare
Updated. PTAL |
|
thanks everyone :) |
|
DKMS works for for me now, installed nvidia DKMS-drivers for both an llvm/clang-kernel and a gcc-kernel with pacman-hooks, so I'm happy :-) |
How? It always errors out for me with invalid kernel config. |
@RyanHakurei can you post your error message (and log file if the error message says anything about writing an error to a log file , IIRC)? Perhaps file a new issue with that info and CC me plz? |
|
@nickdesaulniers Lemme get a new issue fired up, because no modules build successfully I just mentioned Nvidia since you mentioned it working. For anyone else following this: #222 |
7 participants
When building the Linux kernel, one may use
make LLVM=1to setmultiple flags, akin to
make CC=clang LD=ld.lld NM=llvm-nm ...(seethe link below for kernel docs explaining this further in detail).
When building kernel modules, to ensure we're using the same toolchain
as the underlying core kernel image, Kbuild will error if it's reinvoked
with a toolchain that differs. This causes DKMS to fail, since it's not
re-specifying the same compiler (or linker, etc).
Check the .comment section of the vmlinux file in the Linux kernel
source dir, and set CC= and LD= flags for make based on that.
If vmlinux does not exist, grep .config for CONFIG_CC_IS_CLANG=y and
CONFIG_LD_IS_LLD=y.
Fixes: #124
Fixes: ClangBuiltLinux/linux#1104
Link: https://docs.kernel.org/kbuild/llvm.html
Suggested-by: Colin Ian King colin.king@canonical.com
Signed-off-by: Nick Desaulniers nick.desaulniers@gmail.com