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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
