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

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

In D80791#2209624 <https://reviews.llvm.org/D80791#2209624>, @nsz wrote:

> In D80791#2207203 <https://reviews.llvm.org/D80791#2207203>, @chill wrote:
>
>> I would prefer to avoid the situation where the markings of two otherwise identical files were different,
>> depending on how the files were produced, no matter if it was a common or a special case.
>
> i don't see why it is desirable to silently get marking on an object file if function definitions happen to be bti compatible in it:

It is desirable to get the marking because BTI-compatible functions don't appear by accident - they are a result of deliberate user actions, which clearly
express intent to use BTI.

> - compiler cannot reliably do this (e.g. bti incompatible inline asm).

Like for any other case, that's entirely the responsibility of the user if they use inline asm; Command-line options are not
special with regard to inline asm, so everything that can break attribute-derived marking, breaks command-line derived marking.

> - some users don't want the marking: not all linkers support it so it can cause unexpected breakage.

Those linkers would need to be upgraded if the compiler imposes extra requirements on them.  One can't hold the compiler hostage to obsolete linkers. If users insist, they can just remove the .note section.

> - most users (all?) want the marking reliably (not opportunistically), but function annotations are fragile (can depend on optimizations and code outside of user control).

The user explicitly marking an object is the least reliable option, because it's done without regard what the object in actually contains.

> - 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.

> - but a compiler cannot diagnose if only some functions have the annotation (we don't have a cflag for it) so even if the compiler tried to add the marking silently users cannot rely on it: it's too easy to drop the marking and no way to debug such failure.

At the time a compiler decides to or decides not to emit instructions which implement PAC-RET or BTI is perfectly clear what;s the effective annotation for each individual function.

I don't really understand the point of all these objections.

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.


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

https://reviews.llvm.org/D80791