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

2020-09-16 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss updated this revision to Diff 292250. danielkiss added a comment. Rebased top of D85649 . CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://reviews.llvm.org/D80791 Files: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

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

2020-09-02 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. LGTM, as soon as D85649 is accepted (so they stay in sync). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://reviews.llvm.org/D80791 ___ cfe-commits mailing list

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

2020-08-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss updated this revision to Diff 288775. danielkiss edited the summary of this revision. danielkiss added a comment. Sync with D85649 . CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://reviews.llvm.org/D80791 Files:

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

2020-08-21 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In D85649 I suggested a different version of module flags, which is a bit nicer to use, e.g. one can say just getModuleFlag("sign-return-address-with-bkey") != nullptr instead of a) checking for the flag presence, b) getting its value

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

2020-08-11 Thread Szabolcs Nagy via Phabricator via cfe-commits
nsz added a comment. In D80791#2210207 , @chill wrote: > In D80791#2210124 , @danielkiss > wrote: > it is not useful to have a bti annotated function unless everything else is bti compatible too: it is

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

2020-08-11 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In 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

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

2020-08-11 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss added a comment. >> 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

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

2020-08-11 Thread Szabolcs Nagy via Phabricator via cfe-commits
nsz added a comment. In D80791#2209703 , @chill wrote: > In 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

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

2020-08-11 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In D80791#2209624 , @nsz wrote: > In D80791#2207203 , @chill wrote: > >> I would prefer to avoid the situation where the markings of two otherwise >> identical files were different, >>

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

2020-08-11 Thread Szabolcs Nagy via Phabricator via cfe-commits
nsz added a comment. In 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

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

2020-08-10 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. 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. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/

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

2020-08-10 Thread Szabolcs Nagy via Phabricator via cfe-commits
nsz added a comment. In D80791#2206933 , @chill wrote: > In D80791#2206853 , @nsz wrote: > >> i think that cannot work. >> >> the implementation is free to inject arbitrary code into >> user code so if the user

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

2020-08-10 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In 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

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

2020-08-10 Thread Szabolcs Nagy via cfe-commits
The 08/10/2020 10:03, Momchil Velikov via Phabricator wrote: > chill added a comment. > > In D80791#2196598 , @nsz wrote: > > > the assumption is that the intended branch protection is implied via > > cmdline flags for the tu and function attributes are

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

2020-08-10 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In D80791#2196598 , @nsz wrote: > the assumption is that the intended branch protection is implied via cmdline > flags for the tu and function attributes are only used in source code for > some hack. I don't share this

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

2020-08-05 Thread Momchil Velikov via Phabricator via cfe-commits
chill added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:5550 +auto = CGM.getLLVMContext(); +M->addModuleFlag(llvm::Module::Override, "sign-return-address", + Scope == LangOptions::SignReturnAddressScopeKind::All

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

2020-08-05 Thread Szabolcs Nagy via Phabricator via cfe-commits
nsz added a comment. the gcc behaviour is not exactly ideal, but it's better if llvm is compatible with it or fix gcc if something is broken there. the assumption is that the intended branch protection is implied via cmdline flags for the tu and function attributes are only used in source code

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

2020-08-05 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss updated this revision to Diff 283172. danielkiss edited the summary of this revision. danielkiss added a comment. This version of the patch behaves as `gcc` for case when no function present and when function has `-mbranch-protection` attribute without compiler flag. The logic should

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

2020-08-04 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. In D80791#2164543 , @danielkiss wrote: >> If any function has the attribute "sign-return-address", then the output note >> section should have PAC bit set. The return address signing is completely >> local >> to the function, and

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

2020-07-21 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss added a comment. > If any function has the attribute "sign-return-address", then the output note > section should have PAC bit set. The return address signing is completely > local > to the function, and functions with or without return address signing can be > freely mixed with

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

2020-07-21 Thread Momchil Velikov via Phabricator via cfe-commits
chill added a comment. I don't think this behaviour is correct with regard to the specification (AAELF64 2020Q2): > Static linkers processing ELF relocatable objects must set the feature bit in > the output object or image > only if all the input objects have the corresponding feature bit

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

2020-06-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss added a comment. In D80791#2120755 , @kees wrote: > In D80791#2120503 , @nickdesaulniers > wrote: > > > Might someone wish to disable PAC/BTI on an individual function, while > > having it on for the

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

2020-06-29 Thread Kees Cook via Phabricator via cfe-commits
kees added a comment. In D80791#2120503 , @nickdesaulniers wrote: > Might someone wish to disable PAC/BTI on an individual function, while having > it on for the rest? I guess that would mean you can't call that function > indirectly? It would mean

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

2020-06-29 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment. In D80791#2120090 , @kees wrote: > Should the per-function analysis warning actually be removed? That seems like > a helpful check to catch a different form of bad behavior. Might someone wish to disable PAC/BTI on an

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

2020-06-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss added a comment. Function level attributes could set different attributes for functions. If function attribute is used then I assume the user know what he/she is doing so no need to emit a warning. Maybe some would ensure the function is only directly called and never called

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

2020-06-29 Thread Kees Cook via Phabricator via cfe-commits
kees added a comment. Specifically, this appears to be a legitimate bug, found by the warnings: https://bugs.llvm.org/show_bug.cgi?id=46258 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://reviews.llvm.org/D80791

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

2020-06-29 Thread Kees Cook via Phabricator via cfe-commits
kees added a comment. Should the per-function analysis warning actually be removed? That seems like a helpful check to catch a different form of bad behavior. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/

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

2020-06-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss added a comment. This patch solve this too: https://bugs.llvm.org/show_bug.cgi?id=46480 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80791/new/ https://reviews.llvm.org/D80791 ___

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

2020-05-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss created this revision. danielkiss added reviewers: tamas.petz, chill. Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls. Herald added projects: clang, LLVM. Generate .note.gnu.property for PAC and BTI if the compile unit is compiled with -mbranch-protection.