https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
--- Comment #15 from Nick Desaulniers <ndesaulniers at google dot com> --- (In reply to Fangrui Song from comment #14) > Can a no_profile_instrument_function function be inlined into a function > without the attribute? This may be controversial but I'd argue that it can. > GCC no_stack_protector behaves this way. no_profile_instrument_function can > mean that user does not want profiling when the function is called with its > entity, not via another entity. I respectfully but strongly disagree. It's surprising to developers when they ask for no stack protector, or no profiling instrumentation, then get one anyways. For long call chains, it's hard for developers to diagnose on their own which function they called that missed such function attribute. This reminds me of "what color is your function?" https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ As suddenly a developer would need to verify for a no_* attributed function that they only call no_* attributed functions, or add noinline (which is a big hammer to all call sites, and games with aliases that have the noinline attribute are kind of ridiculous). It's less surprising to prevent inline substitution upon function attribute mismatch. Then a developer can self diagnose with -Rpass=inline. Either way, some form of diagnostics would be helpful for these kinds of issues, and has been requested by Android platform developers working on Zygote. For no_stack_protector in LLVM, I implemented the rules: upon mismatch, prevent inline substitution unless the user specified always_inline. This fixed suspend/resume bugs in x86 Linux kernels when built with LTO. Though, I'm happy to revisit that behavior in LLVM; we could add #define noinline_for_lto __attribute__((__noinline__)) then use that in the Linux kernel instead.
