[all-commits] [llvm/llvm-project] c4d9cd: [LLD][ELF][AArch64] Add BTI Aware long branch thun...

[Peter Smith via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c4d9cd8b747cb399a61dd987eb95ad518eb15448
      https://github.com/llvm/llvm-project/commit/c4d9cd8b747cb399a61dd987eb95ad518eb15448
  Author: Peter Smith <peter.smith at arm.com>
  Date:   2024-10-01 (Tue, 01 Oct 2024)

  Changed paths:
    M lld/ELF/Arch/AArch64.cpp
    M lld/ELF/Relocations.cpp
    M lld/ELF/Relocations.h
    M lld/ELF/Target.h
    M lld/ELF/Thunks.cpp
    M lld/ELF/Thunks.h
    A lld/test/ELF/aarch64-thunk-bti.s

  Log Message:
  -----------
  [LLD][ELF][AArch64] Add BTI Aware long branch thunks (#108989)

When Branch Target Identification BTI is enabled all indirect branches
must target a BTI instruction. A long branch thunk is a source of
indirect branches. To date LLD has been assuming that the object
producer is responsible for putting a BTI instruction at all places the
linker might generate an indirect branch to. This is true for clang, but
not for GCC. GCC will elide the BTI instruction when it can prove that
there are no indirect branches from outside the translation unit(s). GNU
ld was fixed to generate a landing pad stub (gnu ld speak for thunk) for
the destination when a long range stub was needed [1].

This means that using GCC compiled objects with LLD may lead to LLD
generating an indirect branch to a location without a BTI. The ABI [2]
has also been clarified to say that it is a static linker's
responsibility to generate a landing pad when the target does not have a
BTI.

This patch implements the same mechansim as GNU ld. When the output ELF
file is setting the
GNU_PROPERTY_AARCH64_FEATURE_1_BTI property, then we check the
destination to see if it has a BTI instruction. If it does not we
generate a landing pad consisting of:
BTI c
B <destination>

The B <destination> can be elided if the thunk can be placed so that
control flow drops through. For example:
BTI c
<destination>:
This will be common when -ffunction-sections is used.

The landing pad thunks are effectively alternative entry points for the
function. Direct branches are unaffected but any linker generated
indirect branch needs to use the alternative. We place these as close as
possible to the destination section.

There is some further optimization possible. Consider the case:
.text
fn1
...
fn2
...

If we need landing pad thunks for both fn1 and fn2 we could order them
so that the thunk for fn1 immediately precedes fn1. This could save a
single branch. However I didn't think that would be worth the additional
complexity.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
[2] https://github.com/ARM-software/abi-aa/issues/196



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications