All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	clang-built-linux@googlegroups.com,
	"H . J . Lu" <hjl.tools@gmail.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Brian Gerst <brgerst@gmail.com>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Chao Yu <chao@kernel.org>, "Darrick J. Wong" <djwong@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	Ingo Molnar <mingo@redhat.com>, Jaroslav Kysela <perex@perex.cz>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Jethro Beekman <jethro@fortanix.com>,
	Kees Cook <keescook@chromium.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Sasha Levin <sashal@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
Date: Sat, 27 Feb 2021 21:51:24 -0800	[thread overview]
Message-ID: <20210228055124.sj3z5n3o5y4w54au@google.com> (raw)
In-Reply-To: <20210227183910.221873-1-masahiroy@kernel.org>

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:)

WARNING: multiple messages have this Message-ID (diff)
From: Fangrui Song <maskray@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: alsa-devel@alsa-project.org,
	Peter Zijlstra <peterz@infradead.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	Sasha Levin <sashal@kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	x86@kernel.org, Jethro Beekman <jethro@fortanix.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Ingo Molnar <mingo@redhat.com>,
	"H . J . Lu" <hjl.tools@gmail.com>,
	Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Brian Gerst <brgerst@gmail.com>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Chao Yu <chao@kernel.org>, Nathan Chancellor <nathan@kernel.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sean Christopherson <seanjc@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	clang-built-linux@googlegroups.com,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC] x86: remove toolchain check for X32 ABI capability
Date: Sat, 27 Feb 2021 21:51:24 -0800	[thread overview]
Message-ID: <20210228055124.sj3z5n3o5y4w54au@google.com> (raw)
In-Reply-To: <20210227183910.221873-1-masahiroy@kernel.org>

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:)

  parent reply	other threads:[~2021-02-28  5:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-27 18:39 [PATCH RFC] x86: remove toolchain check for X32 ABI capability Masahiro Yamada
2021-02-27 18:39 ` Masahiro Yamada
2021-02-28  3:15 ` Masahiro Yamada
2021-02-28  3:15   ` Masahiro Yamada
2021-02-28  6:49   ` Nathan Chancellor
2021-02-28  6:49     ` Nathan Chancellor
2021-02-28  6:52     ` Nathan Chancellor
2021-02-28  6:52       ` Nathan Chancellor
2021-02-28  7:07       ` Masahiro Yamada
2021-02-28  7:07         ` Masahiro Yamada
2021-06-07  7:39     ` Masahiro Yamada
2021-06-08 17:26       ` Nathan Chancellor
2021-02-28  5:51 ` Fangrui Song [this message]
2021-02-28  5:51   ` Fangrui Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210228055124.sj3z5n3o5y4w54au@google.com \
    --to=maskray@google.com \
    --cc=0x7f454c46@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=chang.seok.bae@intel.com \
    --cc=chao@kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=djwong@kernel.org \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jethro@fortanix.com \
    --cc=jgg@ziepe.ca \
    --cc=keescook@chromium.org \
    --cc=krisman@collabora.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=luto@kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=perex@perex.cz \
    --cc=peterz@infradead.org \
    --cc=sashal@kernel.org \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.