https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98997
Bug ID: 98997
Summary: Linking mismatched -fcf-protection objects generates
incorrect code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat cet1.c
#include <setjmp.h>
void test(jmp_buf buf)
{
__builtin_longjmp(buf, 1);
}
$ cat cet2.c
#include <setjmp.h>
void test(jmp_buf buf);
int main()
{
jmp_buf buf;
if (__builtin_setjmp(buf) == 0)
test(buf);
return 0;
}
$ gcc -c -O2 cet1.c -fcf-protection=full
$ gcc -c -O2 cet2.c
$ gcc -o cet -O2 cet1.o cet2.o
$ ./cet
Illegal instruction (core dumped)
Presumably the magic CET fixup in the builtin setjmp/longjmp requires that
matching code is generated for both. I'm testing on a non-CET system.
I haven't even tried to figure out if anything sensible happens to the CET GNU
property, but I think the current GCC behavior is impolite at best. I think
GCC should do one of a few things:
1. Generate working code.
2. Fail to link.
3. At least document this pitfall very clearly.
I really hope this doesn't affect shared objects.
