You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#282 added some text alongside the GNU property description of BTI to define what a code-generator could assume about the static linker.
While this may have been the most convenient place to put the information. This is strictly speaking not just restricted to the sysvabi. Bare-metal and non-sysv platforms may use BTI. Windows on Arm and Darwin will need to choose their own platform ABI for BTI, if they support it at all.
#282 added some text alongside the GNU property description of BTI to define what a code-generator could assume about the static linker.
While this may have been the most convenient place to put the information. This is strictly speaking not just restricted to the sysvabi. Bare-metal and non-sysv platforms may use BTI. Windows on Arm and Darwin will need to choose their own platform ABI for BTI, if they support it at all.
Thoughts:
The https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#577call-and-jump-relocations should mention that static linkers cannot assume a BTI at the destination. Add a reference to the sysvabi text for more details.
Being "indirectly callable" could be considered part of the Procedure Call standard too, on requirements for callees when BTI is enabled.
The text was updated successfully, but these errors were encountered: