[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.
Szabolcs Nagy via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 11 07:27:51 PDT 2020
nsz added a comment.
In D80791#2209703 <https://reviews.llvm.org/D80791#2209703>, @chill wrote:
> In D80791#2209624 <https://reviews.llvm.org/D80791#2209624>, @nsz 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.
the current design is per elf module, so the non-guarded things have to go into a different elf module (and thus different tu).
i think the only way the current abi supports mixing bti and non-bti code is if all the linker inputs to the elf module are marked as bti compatible and then the user explicitly unprotects some region at runtime, i.e. bti is still all or nothing per elf module, but a user might want to do some hack and turn bti off in some places.
> With my proposal to derive marking from function attributes, as well as from command-line
> everything above will still work in the (arguably) most common case that we expect - users just using
> command line.
>
> I'm proposing to be strict and cover a few corner case where the command-line only approach produces bogus results.
ok i think deriving the marking in the absence of command-line option works, but it's not something users can rely on and not what gcc does.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D80791/new/
https://reviews.llvm.org/D80791
More information about the cfe-commits
mailing list