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

            Bug ID: 114447
           Summary: -fstack-protector-explicit ignored
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joakim.rosqvist at gmail dot com
  Target Milestone: ---

When I compile (gcc -v says 13.2.0-4ubuntu3)  this minimal C program to
assembly:

int main(int, char *[])
{
    return 0;
}

>gcc -fverbose-asm -S -o foo.s foo.c

I can see in the generated foo.s file that a few extra options were given to
the compiler:

# options passed: -mtune=generic -march=x86-64 -fasynchronous-unwind-tables
-fstack-protector-strong -fstack-clash-protection -fcf-protection

Presumably, these are wisely chosen built-in defaults in gcc.

Now let's add another option to the command line:

>gcc -fno-stack-protector -fverbose-asm -S -o foo.s foo.c

In the generated assembly we now get:

# options passed: -mtune=generic -march=x86-64 -fno-stack-protector
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

I.e. -fno-stack-protector  was added  and -fstack-protector-strong was removed
as the compiler correctly deduced that these conflict with each other and so
let the user-supplied option "win".  Everything is fine so far.

Now, let's compile like so:

>gcc -fstack-protector-explicit -fverbose-asm -S -o foo.s foo.c

The relevant resulting line is:

# options passed: -mtune=generic -march=x86-64 -fstack-protector-explicit
-fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection
-fcf-protection

I.e. this time the compiler did NOT understand that there is a conflict between
-fstack-protector-explicit  and builtin -fstack-protector-strong.
The first one should generate stack protection code only for functions with the
stack-protector attribute, while the second one should generate stack
protection code for all functions when possible.
Here -fstack-protector-strong wins and all functions get stack protection
regardless of whether they have the attribute.   So the user-supplied option is
effectively ignored.

Reply via email to