| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
-mno-speculative-load-hardening isn't a cc1 option, therefore,
before this change:
clang -mno-speculative-load-hardening hello.cpp
would have the following error:
error: unknown argument: '-mno-speculative-load-hardening'
This change will only ever forward -mspeculative-load-hardening
which is a CC1 option based on which flag was passed to clang.
Also added a test that uses this option that fails if an error like the
above is ever thrown.
Thank you ericwf for help debugging and fixing this error.
Reviewers: chandlerc, EricWF
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54763
llvm-svn: 347582
|
|
|
Load Hardening.
Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.
Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.
While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.
This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.
Differential Revision: https://reviews.llvm.org/D51157
llvm-svn: 341363
|
