https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
Fangrui Song <i at maskray dot me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |i at maskray dot me
--- Comment #7 from Fangrui Song <i at maskray dot me> ---
(In reply to Martin Liška from comment #6)
> Implemented.
#include <string.h>
void foo(const char *a) { char b[34]; strcpy(b, a); }
__attribute__((no_stack_protector))
void bar(const char *a) { foo(a); }
#include <string.h>
__attribute__((no_stack_protector))
void foo(const char *a) { char b[34]; strcpy(b, a); }
void bar(const char *a) { foo(a); }
In both cases, foo can be inlined.
In Clang, the recent resolution https://reviews.llvm.org/D91816 is that a ssp
function cannot be inlined into a nossp function and a nossp function cannot be
inlined into a ssp function.
I think one argument for the no-inline behavior is that ssp conveys the
security enforcement intention and the GCC behavior may degrade the security
hardening while inlining a ssp chunk.
Previously Clang upgraded the caller from nossp to ssp after inlining. However,
that behavior caused
https://lore.kernel.org/lkml/20200422192113.gg26...@zn.tnic/T/#t
(the caller may not have set up %gs and upgrading it to ssp can break it)
The new Clang behavior also disallows a nossp callee from being inlined into a
ssp caller. That makes the rules easier to explain but I haven't thought very
clearly about the implications though.
