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

[Szabolcs Nagy via Phabricator via cfe-commits]

nsz added a comment.

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

> In D80791#2206853 <https://reviews.llvm.org/D80791#2206853>, @nsz wrote:
>
>> i think that cannot work.
>>
>> the implementation is free to inject arbitrary code into
>> user code so if the user does not tell the implementation
>> that it wants the entire tu to be bti safe then non-bti
>> code can end up in there. (e.g. ctor of an instrumentation
>> that is not realated to any particular function with the
>> bti marking)
>
> Certainly, there are cases it won't work, but there are definitely
> cases where it *can* work. Whatever the implementation does
> should be a deterministic consequence of implementing the relevant
> language standards together with implementation-defined behaviour,
> command-line options and language extensions (e..g attributes).
>
> Certainly I don't expect C++ ctorts/dtors in C code and gcov or
> sanitiser calls if I haven't given relevant `-fprofile-whatever`/`-fsanitize=whatever`
> options. In that sense, the implementation cannot do whatever
> it pleases, it is constrained to a range of behaviours one can reason about.

i think it's a bad idea to use function level
attributes to control what markings we attach to
translation units and i would prefer to only add
markings to object files when the compiler is
asked to do so per tu.

i dont want to see source code changes
to enable bti, that should be only needed
for some special case that's way out of
standard conform code.


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

https://reviews.llvm.org/D80791