From: Mark Rutland <mark.rutland@arm.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
D Scott Phillips <scott@os.amperecomputing.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: Revisiting c0a454b9044f
Date: Tue, 15 Jul 2025 12:16:07 +0100 [thread overview]
Message-ID: <aHY4d46ehF-j_pbw@J2N7QTR9R3> (raw)
In-Reply-To: <20250714195205.GA3723043@ax162>
On Mon, Jul 14, 2025 at 12:52:05PM -0700, Nathan Chancellor wrote:
> Hi all,
Hi Nethan,
> I am looking to potentially bump the minimum version of LLVM for
> building the kernel to 15.0.0 after the next merge window. In my quest
> to look for workarounds that can be dropped, I noticed that
> CONFIG_ARM64_BTI_KERNEL was disabled unconditionally for GCC in commit
> c0a454b9044f ("arm64/bti: Disable in kernel BTI when cross section
> thunks are broken") as a result of [1]. Looking at that GCC report, it
> seems like the AArch64 ABI now documents [2] the GNU toolchain's
> behavior as expected
For context, at the time of commit c0a454b9044f, GNU LD did not handle
this appropriately, leading to runtime BTI failures where two sections
were too far apart.
GNU LD was subsequently fixed, and the ABI documentation was updated,
but I'm not sure which specific versions of GNU LD have the fix, and we
hadn't chased that up to re-enable BTI with GCC.
> and LLVM has been adjusted [3][4][5] to match. Do I need to block
> CONFIG_ARM64_BTI_KERNEL from being selected with LLVM 21.0.0?
I'm missing something; why would we need to dsiable BTI in that case?
The concern from the kernel side is simply whether we get unexpected BTI
failures. IIUC so long as compiler and linker agree we should be good,
and we simply need to forbid broken combinations.
> Or should the kernel adjust its expectations now that the ABI and
> toolchains all agree?
Yes, we can probably rework this.
IIUC we'd need to forbid BTI with:
* GCC + old GNU LD
* GCC + old LLD
* new clang + old GNU LD
* new clang + old LLD
... and can enable BTI otherwise.
Does that make sense to you?
Mark.
> Cheers,
> Nathan
>
> [1]: https://gcc.gnu.org/pr106671
> [2]: https://github.com/ARM-software/abi-aa/commit/606ce44fe4d3419c15cd9ed598f18fb5d520fcfc
> [3]: https://github.com/llvm/llvm-project/commit/7af2b51e761f49974a64c3009882239cea618f2a
> [4]: https://github.com/llvm/llvm-project/commit/edf21314c98a4fe05d48f83dfab2b201ed8bfe9c
> [5]: https://github.com/llvm/llvm-project/commit/098b0d18add97dea94e16006486b2fded65e228d
next prev parent reply other threads:[~2025-07-15 11:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 19:52 Revisiting c0a454b9044f Nathan Chancellor
2025-07-15 11:16 ` Mark Rutland [this message]
2025-07-16 18:26 ` Nathan Chancellor
2025-07-17 13:47 ` Mark Rutland
2025-12-30 15:06 ` ARM64_BTI_KERNEL and gcc? (was Re: Revisiting c0a454b9044f ) Mikko Rapeli
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=aHY4d46ehF-j_pbw@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nathan@kernel.org \
--cc=scott@os.amperecomputing.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox