[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

[Szabolcs Nagy via Phabricator via cfe-commits]

nsz added a comment.

In D80791#2210207 <https://reviews.llvm.org/D80791#2210207>, @chill wrote:

> In D80791#2210124 <https://reviews.llvm.org/D80791#2210124>, @danielkiss wrote:
>
>>>> it is not useful to have a bti annotated function unless everything else is bti compatible too: it is all or nothing per elf module.
>>>
>>> This is false. Some functions in an elf module could be in a guarded region, some in a non-guarded region. Some function may always
>>> be called in a "BTI-safe" way, which may be unknown to the compiler.
>>
>> Right now the elf and all of the `text` sections considered BTI enabled or not. The dynamic linkers/loaders can't support this
>> use case without additional information to be encoded somewhere (and specified). To support such we need to consider grouping/align to page
>> boundaries these functions in the linker because BTI could be controlled by flags in PTE.
>> With the current spec this usecase is not supported in this way. The user have to link the BTI protected code into another elf.
>> Side note: The `force-bti` linker option can't work with half BTI enabled objects.
>
> I suppose this is valid for typical Linux-based systems today.
>
> Is it valid in general, across the whole spectre of operating systems or for bare-metal targets?
>
> Guess not.

the linker may or may not need to generate code (PLT is just one example) and the current abi is designed such that it is an elf module level decision if that code is bti compatible or not.

this is why i said that the current abi does not support mixed bti and non-bti code, however the user can do this if lies to the linker that everything is bti compatible so the linker generates stub code accordingly.

i don't see how baremetal can get away here: this is elf abi.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80791/new/

https://reviews.llvm.org/D80791