[sysvabi64] Document requirements for tools wrt BTI #282
Conversation
|
LLD patch to implement BTI aware thunks llvm/llvm-project#108989 |
sysvabi64/sysvabi64.rst
Outdated
|
|
||
| A relocatable object producer is required to add a BTI instruction to | ||
| a location when the address of that location escapes out of the | ||
| relocatable object. This includes the locations of all symbols that |
There was a problem hiding this comment.
Pedantry: surely only when the address of a location escapes from the object with some reasonable intention that other objects will use it as an indirect call destination.
If it escapes purely by accident (I loaded it into x1 within my own function, then returned a value in x0), or as the address of something other than code (like a string literal), that's not intended to be covered by this text.
There was a problem hiding this comment.
I'm thinking about how to write this without tying myself in knots. My current favourite is
"the address of that location is live and escapes out of the relocatable object." That should cover the case where the address of the is in a register or memory but there's no reader.
|
Apologies for the force push, needed to rebase to pick up the new github actions. |
Add requirements for when a tool must generate a BTI instruction. This permits tools to elide BTI instructions when they can prove that no indirect branch to that location is possible from local information available to the tool. Static linkers are not allowed to assume that all direct branch targets have a BTI instruction. If a veneer is required then the static linker must generate additional BTI instructions if needed. A static linker is allowed to assume that a symbol that is exported to the dynamic symbol table has a BTI instruction. In practice this will permit compilers to remove BTI instructions from static functions that do not have their address taken and that address escapes the function. This matches the behavior of the GNU toolchain. Fixes ARM-software#196
It is possible to provide a static linker with branch targets using absolute symbols. For example using --defsym. The static cannot disassemble the location of these symbols so it isn't possible to check whether A BTI landing pad is necessary, nor is it always possible to place a BTI landing pad within range of the absolute symbol address. A user providing the static linker with function addresses using absolute symbols is responsible for putting BTI compatible landing pads at the start of these addresses.
An address may be in registers or memory, but not live, the object producer may assume that this address does not require a BTI.
sysvabi64/sysvabi64.rst
Outdated
| the number of indirect branch destinations in the program. The | ||
| following tool requirements determine which tool has the | ||
| responsibility of inserting the BTI instruction, permitting a tool to | ||
| elide the BTI instuction when it can prove that there are no indirect |
sysvabi64/sysvabi64.rst
Outdated
| elide the BTI instuction when it can prove that there are no indirect | ||
| calls to that location. | ||
|
|
||
| A relocatable object producer is required to add a BTI instruction to |
There was a problem hiding this comment.
Consider putting each requirement in a list item.
sysvabi64/sysvabi64.rst
Outdated
|
|
||
| .. code-block:: asm | ||
|
|
||
| // Linker generated veneer using indirect bracnh |
sysvabi64/sysvabi64.rst
Outdated
|
|
||
| A static linker that uses indirect branches in veneers is required to | ||
| generate a BTI compatible landing pad if the target of the indirect | ||
| branch is defined within the same link unit and does not have a |
There was a problem hiding this comment.
Can you please clarify why "if ... defined within the same link unit" is necessary? What happens in the case where the target is defined in another link unit?
There was a problem hiding this comment.
I've gone with a more abstract escapes to an opaque entity. The original text refers to the boundary between the compiler/assembler and linker, but it can be more general than that. For example inline assembly that the compiler can't see into could indirect branch if the escaped address were on the input list.
The intent is that if the address of a location escapes to somewhere that the tool can't prove that no indirect branch might be generated. Originally relocatable object was used to indicate the interface between the compiler/assembler and static linker.
sysvabi64/sysvabi64.rst
Outdated
| the number of indirect branch destinations in the program. The | ||
| following tool requirements determine which tool has the | ||
| responsibility of inserting the BTI instruction, permitting a tool to | ||
| elide the BTI instuction when it can prove that there are no indirect |
sysvabi64/sysvabi64.rst
Outdated
| elide the BTI instuction when it can prove that there are no indirect | ||
| calls to that location. | ||
|
|
||
| A relocatable object producer is required to add a BTI instruction to |
sysvabi64/sysvabi64.rst
Outdated
|
|
||
| A static linker that uses indirect branches in veneers is required to | ||
| generate a BTI compatible landing pad if the target of the indirect | ||
| branch is defined within the same link unit and does not have a |
There was a problem hiding this comment.
I've gone with a more abstract escapes to an opaque entity. The original text refers to the boundary between the compiler/assembler and linker, but it can be more general than that. For example inline assembly that the compiler can't see into could indirect branch if the escaped address were on the input list.
sysvabi64/sysvabi64.rst
Outdated
|
|
||
| .. code-block:: asm | ||
|
|
||
| // Linker generated veneer using indirect bracnh |
Text under bullet was not indented properly.
|
Ok by me. Thanks. But please wait for another approval. |
Add requirements for when a tool must generate a BTI instruction. This permits tools to elide BTI instructions when they can prove that no indirect branch to that location is possible from local information available to the tool.
Static linkers are not allowed to assume that all direct branch targets have a BTI instruction. If a veneer is required then the static linker must generate additional BTI instructions if needed.
A static linker is allowed to assume that a symbol that is exported to the dynamic symbol table has a BTI instruction.
In practice this will permit compilers to remove BTI instructions from static functions that do not have their address taken and that address escapes the function.
This matches the behavior of the GNU toolchain.
Fixes #196