[PATCH] Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute

[Peter Collingbourne]

> maybe we should at least not document it?


I'd rather document it than have some undocumented attribute in use somewhere.

I'll take a shot at implementing no_sanitize tomorrow and hopefully make this a moot point.


================
Comment at: lib/CodeGen/CodeGenModule.cpp:765
@@ -763,1 +764,3 @@
+        !D->hasAttr<NoSafeStackAttr>())
+      B.addAttribute(llvm::Attribute::SafeStack);
   }
----------------
samsonov wrote:
> Do you also need to add it to `CodeGenModule::CreateGlobalInitOrDestructFunction`?
Yes, done.

================
Comment at: lib/Driver/Tools.cpp:2354
@@ +2353,3 @@
+  if (SanArgs.needsSafeStackRt()) {
+    if (Args.hasArg(options::OPT_shared)) {
+      // This is a temporary limitation caused by linking issues.
----------------
samsonov wrote:
> This code is now dead - presence of `-shared` is checked at the top of this function. Can we silently discard `-fsanitize=safe-stack` while linking DSO?
We can, but only if the DSO is linked against a main executable that is linked against the safe stack runtime. (Generally for the other sanitizers we can make this true, but in deployment scenarios you might not be able to control the main executable.)

There are a number of possible solutions to this problem, which we plan to deal with in a future change, but at least removing the check makes things work in that specific scenario. So I've removed it.

================
Comment at: lib/Driver/Tools.cpp:6251
@@ +6250,3 @@
+    getMachOToolChain().AddLinkRuntimeLib(Args, CmdArgs,
+                                          "libclang_rt.safestack_osx.a");
+
----------------
samsonov wrote:
> Looks like you should set `AlwaysLink` argument of `AddLinkRuntimeLib` to `true`.
Done

http://reviews.llvm.org/D6095

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/