aarch64 build fails #151
Comments
Likely bad gcc flags or bad compiler. Can you build any non-trivial kernel modules in your build environment? |
|
the proprietary version of the modules build fine in the same environment |
|
It does not build nearly as much code as this one. Anyway, you can try to build with V=1 and see if there is any difference in the flags passed to the compiler. |
|
Note that rather than V=1, to enable verbose output for all of this build, add To debug unresolved symbol problems, I normally do something like this:
That will tell you which object files call the symbol and which object files define the symbol. From a few google searches, I think the aarch64 build may need "-mno-outline-atomics" (some gcc configs apparently have -moutline-atomics enabled by default). Does the following change fix the problem? |
|
@aritger the above patch fixes the build, thanks 👍 |
Add NVIDIA open gpu kernel modules Ref: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ Fix [arm64 build](NVIDIA/open-gpu-kernel-modules#151) Signed-off-by: Noel Georgi <git@frezbo.dev>
|
According to documentation of recent GCC -mno-outline-atomics is required if you are building for -march=armv8-a (without lse) and your environment does not have libgcc (which the kernel does not). Building for -march=armv8-a+lse, -march=armv8.1-a, or any later architecture avoids the helpers for lse detection because the instructions are assumed to be available, and conversely -mno-outline-atomics generates pure armv8-a code without lse instructions. The question is what's the desired outcome, how the architecture gets picked, and for what architecture nVidia builds the binary drivers. Seeing the build output with the verbose flag would answer these questions. I can only guess that the build uses -march=native and builds for some arbitrary architecture that nVidia uses in-house while this emulated environment is armv8-a leading to gcc generating the compatibility helpers. |
|
Please condition the use of GCC version wouldn’t be a nice heuristics because some distributions got it backported… |
|
Attaching the full build log with |
|
Thanks, so either flag does equally good job at showing the compiler flags.
is explicitly passed. This flag is present in a few files in the project and you can amend it with eg.
nVidia is propbably using an older compiler that does not support these lse helpers and Using |
can confirm this seems accurate |
|
Thanks for the thorough comments, @hramrach. In general, we try to build one binary that runs across a large set of CPUs. For now, I'd be reluctant to change -march. TEST_CC_ARG can be used in the makefile to test if the compiler supports the flag, so I hope this is a workable solution: |
|
Why is it added to CONDITIONAL_CFLAGS and not CFLAGS? Also this is only 1 of the 3 places that have -march=armv8-a |
|
@hramrach to not break compatibility with configs that use older compilers. Enabling LSE by default would break CPUs as recent as the Cortex-A72 and the ThunderX... so it's not a good option at all. |
|
While there are multiple places where CONDITIONAL_CFLAGS are set I do not see any place where they are used, and they do not exist in the kernel at all. Also it's the TEST_CC_ARG conditional that prevents breaking older compiles, not assignment to a different variable. |
|
FYI - our next release should contain a fix for this. @hamrach: you are correct, there were three places that required updating. The assignment to The difference, though, is that CONDITIONAL_CFLAGS is a simply expanded gnu make variable: whereas CFLAGS is a recursively expanded gnu make variable (these different types of variables are described on https://www.gnu.org/software/make/manual/make.html#Flavors ) Normally, recursively expanded is more idiomatic in make. But, the use of TEST_CC_ARG triggers a test invocation of the compiler, and we want to do that only once, rather than each time CFLAGS is used. |
|
This should be fixed in 515.48.07. Please let me know if you continue to have troubles. Marking fixed. |
Describe the bug
aarch64 compilation fails
To Reproduce
Building using qemu aarch64 emulation
The text was updated successfully, but these errors were encountered: