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