llvm/clang - add polly support, add SSP-by-default
Now that edge contains a recent version of isl, we can make use of polly (somewhat similar to gcc’s graphite) in clang to enable more interesting loop optimizations and exposing “SIMDization opportunities”. My first patch here does just that. No musl related fixes are needed for polly.
The second patch attached makes sure -Wl,-z,now -Wl,-z,relro is default behavior, as well as enabling more comprehensive stack smashing protection by default.
In hindsight, I probably should have made these changes in the other order. The security stuff could go straight into stable, but unless gcc5 was added to stable when i wasn’t looking, polly needs to live in edge where the version of isl is more friendly. Actually, I would suggest that you do just that. The SSP changes aren’t that significant and actually just mimic what’s already done on OpenBSD.
The automatic GPGPU code generation has been disabled in polly, since it doesn’t appear to work without CUDA (even though it should? I think?).
As for SSP-by-default, the explanation is in the commit message:
clang's normal behavior on linux defaults to using stack smashing protection
whenever a function defines an 8 character or more local array. this is the
equivalent of passing in -fstack-protector with no additional options in gcc.
this release patches clang's default behavior to instead behave like
-fstack-protector-strong was passed in, enabling the canary in many more
conditions without the performance impact of adding it to ALL functions as is
the case with -fstack-protector-all. these conditions include:
local variable's address used as part of right hand side of assignment
local variable's address used as function argument
local variable is an array, regardless of array type or length
same as above, but local variable is a union containing an array
uses register local variables
SSP can still be disabled by passing in -fno-stack-protector.
You can still use -fstack-protector-all to add a canary to all functions.
This isn’t an exhaustive list of conditions where -fstack-protector-strong inserts a canary.
Tests were added alongside this change to make sure the original behavior remains for non-alpine triples, while giving alpine the desired behavior when “alpine” is set as vendor. So if you compile for “i486-pc-linux-gnu” you get standard clang behavior, but “i486-alpine-linux-musl” gets PIE and SSP by default.
My next trick will be to have the main llvm test suite run by default even on grsec kernels by compiling the tests ahead of time and using paxmark.
(from redmine: issue id 4374, created on 2015-06-20, closed on 2015-12-18)