melver added a comment. In D104475#2825297 <https://reviews.llvm.org/D104475#2825297>, @MaskRay wrote:
> Should `no_profile` specify the inlining behavior? Though `no_sanitize_*` > don't specify that, either. I think it's somehow implicit, but I can't quite say how. There are some tests that check this, e.g. compiler-rt/test/asan/TestCases/inline.cpp > As I commented on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 , the > Linux kernel specifies `noinline` so the exact inlining behavior doesn't > matter. > > #define noinstr \ > noinline notrace __attribute((__section__(".noinstr.text"))) \ > __no_kcsan __no_sanitize_address noinstr does add noinline, but other uses of the attribute alone might not. But in the end inlining is a red herring, it just seems to be the easiest way to enforce the promised contract. See https://lore.kernel.org/lkml/canpmjnnrz5ovkb6pe7k6gjfogbht_zhypkng9ad+kjndzk7...@mail.gmail.com/ In particular: > But the contract of > "no_sanitize" is "that a particular instrumentation or set of > instrumentations should not be applied". That contract is broken if a > function is instrumented, however that may happen. Also always_inline needs checking, because it's a little special: >>>> - An __always_inline function inlined into a __no_sanitize function is not >>>> instrumented >>>> - An __always_inline function inlined into an instrumented function is >>>> instrumented This was also previously discussed here: https://lore.kernel.org/lkml/CANpmjNMTsY_8241bS7=xafqvzhflrvekv_um4aduwe_kh3r...@mail.gmail.com/ Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104475/new/ https://reviews.llvm.org/D104475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
