[Bug c/94722] implement __attribute__((no_stack_protector)) function attribute

["ndesaulniers at google dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722

--- Comment #10 from Nick Desaulniers <ndesaulniers at google dot com> ---
(In reply to Jakub Jelinek from comment #9)
> I've said in that thread that I don't really like disabling the inlining, if
> we wanted to make sure everything is stack protected, we'd need to disable
> all the inlining no matter whether the attribute is there or not, because
> inlining by definition removes the stack protector checks, it is only tested
> on function boundaries, not on inline function boundaries.
> The user has the option to add noinline when he wants.

I'm not against reverting my recent change to LLVM's inlining behavior
(https://reviews.llvm.org/D91816, and the follow up to the docs
https://reviews.llvm.org/D93422).  Would be less work to do for inlining
decisions.

In the kernel, we could introduce a macro that's "noinline_for_lto" or
"noinline_due_to_stackprotectors" or such; this specific case only comes about
due to LTO between TUs with -fstack-protector* and -fno-stack-protector and
inlining between them.

Though, I'm still concerned about local cases (forgetting LTO for a moment)
where folks use __attribute__((no_stack_protector)) will basically have to
remember to additionally use __attribute__((noinline)) lest they hit the same
kind of bugs within a TU.  LLVM's current behavior "helps" developers avoid
such pitfalls; otherwise developers will have to be able to diagnose on their
own when such a case arises such that it causes bugs.