Messages in this thread | | | Date | Sat, 27 Feb 2021 21:51:24 -0800 | From | Fangrui Song <> | Subject | Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability |
| |
On 2021-02-28, Masahiro Yamada wrote: >This commit reverts 0bf6276392e9 ("x32: Warn and disable rather than >error if binutils too old"). > >The help text in arch/x86/Kconfig says enabling the X32 ABI support >needs binutils 2.22 or later. This is met because the minimal binutils >version is 2.23 according to Documentation/process/changes.rst. > >I would not say I am not familiar with toolchain configuration, but >I checked the configure.tgt code in binutils. The elf32_x86_64 >emulation mode seems to be included when it is configured for the >x86_64-*-linux-* target. > >I also tried lld and llvm-objcopy, and succeeded in building x32 VDSO. > >I removed the compile-time check in arch/x86/Makefile, in the hope of >elf32_x86_64 being always supported. > >With this, CONFIG_X86_X32 and CONFIG_X86_X32_ABI will be equivalent. >Rename the former to the latter.
Hi Masahiro, the cleanup looks nice!
As of LLVM toolchain support, I don't know any user using LLVM binary utilities or LLD. The support on binary utitlies should be minimum anyway (EM_X86_64, ELFCLASS32, ELFDATA2LSB are mostly all the tool needs to know for many utilities), so many of they should just work.
For llvm-objcopy, I know two issues related to `$(OBJCOPY) -O elf32-x86-64` (actually `objcopy -I elf64-x86-64 -O elf32-x86-64`). Such an operation tries to convert an ELFCLASS64 object file to an ELFCLASS32 object file. It is not very clear what GNU objcopy does. llvm-objcopy is dumb and does not do fancy CLASS conversion.
* {gcc,clang} -gz{,=zlib} produced object files. The Elf{32,64}_Chdr headers are different. Seems that GNU objcopy can convert the headers (https://github.com/ClangBuiltLinux/linux/issues/514). llvm-objcopy cannot do it. * Seems that GNU objcopy can convert .note.gnu.property (https://github.com/ClangBuiltLinux/linux/issues/1141#issuecomment-678798228) llvm-objcopy cannot do it.
On the linker side, I know TLS relaxations and IBT need special care and I believe LLD does not handle them correctly. Thankfully the kernel does not use thread-local storage so this is not an issue. So perhaps for most configurations it is already working. Since you've tested it, that is good news to me:)
| |