Open SilvanScherrer opened 4 years ago
It's not even that, the problem is bigger. Stack protection needs a review. Given this sample code:
#include <stdlib.h>
int main(int argc, const char **argv)
{
int * i2 = alloca (100);
return i2 [10];
}
the compile and link command gcc -Zomf -fstack-protector sandbox.c
fails with:
weakld: cannot open library file '\@unixroot\usr\lib\ssp_nonshared_s.a'.
emxomfld: weak prelinker failed. (rc=8)
I.e. for some reason gcc wants a non-shared version which we don't provide (at least not in RPM).
The compile command gcc -c -Zomf -fstack-protector sandbox.c
works but a subsequent link command gcc -Zomf sandbox.o
fails with:
weakld: error: Unresolved symbol (UNDEF) '___stack_chk_guard'.
weakld: info: The symbol is referenced by:
D:\Coding\Tests\sandbox.o
weakld: error: Unresolved symbol (UNDEF) '___stack_chk_fail'.
weakld: info: The symbol is referenced by:
D:\Coding\Tests\sandbox.o
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: ___stack_chk_guard is an undefined reference
Error! E2028: ___stack_chk_fail is an undefined reference
file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_guard
file D:\Coding\Tests\sandbox.o(sandbox.o): undefined symbol ___stack_chk_fail
This is expected as the linker needs -fstack-protector
as well. Once we add this option to the above link command, we will get the same error about the missing ssp_nonshared_s.a
library as the above. The only link command that works here afterwards is this one:
gcc -Zomf sandbox.o -lssp0.dll
This is certainly not the right flow of things. We should look into that at some point.
See https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html for GCC docs on that.
Sorry for the hassle and discard the previous comment: it's actually solved by simply doing yum install libssp-devel
. It provides all the necessary static libraries and the example compiles and links w/o errors.
@SilvanScherrer what about your problem, there is no way to achieve what you want if the compile and link steps are run as separate commands — the second invocation doesn't have access to the first invocation's compile options. So the only way to go here is to put -fstack-protector
both in CFLAGS and LDFLAGS. This will always work.
Looking at Linux, it looks like __stack_chk_fail
is provided by libc. I guess we should do the same to get rid of the whole libssp hassle. No SSP.DLL will be needed (except for the forwarder for old software), no libssp-devel and no -fstack-protector
in LDFLAGS. But that's postponed for now.
if -fstack-protection is used while compiling I guess -lssp should automatically be added to the LDFLAGS. IIRC it was the case with gcc4.