Messages in this thread |  | | From | Mauro Rossi <> | Date | Sun, 1 May 2022 18:47:32 +0200 | Subject | Re: arch/x86/entry/entry: RFC on recent kernels building error with llvm 11.0.2 internal assembler |
| |
On Sat, Apr 30, 2022 at 11:30 PM Nathan Chancellor <nathan@kernel.org> wrote: > > Hi Mauro, > > [+ llvm@lists.linux.dev and Nick] > > On Fri, Apr 29, 2022 at 07:40:07PM +0200, Mauro Rossi wrote: > > Hi Andy, > > > > I am an hobbyist contributing to android-x86 FOSS project lead by > > Chih-Huwei Huang (in Cc: for information/alignement) > > > > I am performing periodic tests to build kernel for Android 11 based iso image > > which relies on aosp shipped prebuild clang toolchain (clang version 11.0.2) > > > > When building linux 5.18rc4 and also with linux 5.17 x86_64 64bit kernel targets > > there is a building error in arch/x86/entry > > > > AS arch/x86/entry/entry_64.o > > <instantiation>:2:2: error: unknown use of instruction mnemonic > > without a size suffix > > lsl %rax, %rax > > ^ > > <instantiation>:1:1: note: while in macro instantiation > > LOAD_CPU_AND_NODE_SEG_LIMIT %rax > > ^ > > <instantiation>:2:2: note: while in macro instantiation > > GET_PERCPU_BASE %rax > > ^ > > /home/utente/r-x86_kernel/kernel/arch/x86/entry/entry_64.S:890:2: > > note: while in macro instantiation > > SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx > > ^ > > make[3]: *** [/home/utente/r-x86_kernel/kernel/scripts/Makefile.build:389: > > arch/x86/entry/entry_64.o] Error 1 > > make[2]: *** [/home/utente/r-x86_kernel/kernel/scripts/Makefile.build:550: > > arch/x86/entry] Error 2 > > make[1]: *** [/home/utente/r-x86_kernel/kernel/Makefile:1887: arch/x86] Error 2 > > make[1]: *** Waiting for unfinished jobs.... > > > > As other interesting info, the building error does not happen when > > building x86 32bit kernel target and i can build 86_64 64bit kernel > > target only by setting the LLVM_IAS=0 parameter to disable the > > internal llvm assembler > > This error was fixed in LLVM 11.0.0 final, which was released after > Android's LLVM 11.0.2: > > https://github.com/ClangBuiltLinux/linux/issues/1079 > > > I wanted to ask you if you could help us, if there could be a way to > > improve arch/x86/entry/entry_64.S code to be able to complete the > > build without disabling the llvm internal assembler. > > > > I don't know if this building error may be caused by the clang version > > 11.0.2, but at some point the aosp and android version may hit this > > same issue, > > so I wanted to highlight this issue to you to have a competent person feedback, > > as I am more a "trial and error" guy than a kernel expert > > I am open to other opinions but I am not inclined to suggest working > around this in the kernel for two reasons: > > 1. This issue was resolved in the toolchain almost two years ago, so it > is not a recent failure. > > 2. Android's LLVM 11.0.2 is technically older than the minimum version > that the kernel supports (11.0.0), which I would argue means it is > unsupported. 11.0.0 final was released on October 12th, 2020 and > Android's LLVM 11.0.2 was committed on June 11th, 2020, so you are > potentially missing four months worth of fixes: > > https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/431c74471920f3f9b0517692fb69515c023bde41 > > Unfortunately, due to the way that LLVM versions work, it is not so > easy to check for this but perhaps we should consider trying to > handle this, so that others don't continue to trip over old bugs. > > Moving to LLVM_IAS=0 is the solution that we went with for clang-10 when > it was supported after the switch to the integrated assembler by > default, which I do not think is an unreasonable solution for this > issue. > > Alternatively, you could apply the hack that Nick inserted into Android > for this issue if upgrading your toolchain or turning off the integrated > assembler is not possible: > > https://android.googlesource.com/kernel/common/+/e58f084735b8abf744d61083b92172ee23d45aae > > I really do not mean to sound dismissive or rude, I apologize if it > comes off that way, but we have worked quite hard to avoid inserting > unnecessary workarounds, as they are ultimately technical debt that can > be hard to manage over the long term. > > Cheers, > Nathan
Thanks a lot Nathan
It is definitely the clang version 11.0.x which is not updated in aosp Android 11 production tags
I will use Nick's workaround which works since only lsl %rax, %rax is currently happening
Many thanks, problem solved
|  |