[PATCH] D19407: [SafeStack] [SSP] Use llvm.stackguard intrinsic.

Tim Shen via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 27 11:04:52 PDT 2016


timshen added inline comments.

================
Comment at: lib/CodeGen/SafeStack.cpp:400
@@ +399,3 @@
+    TL->insertSSPDeclarations(*M);
+    Function *SG = Intrinsic::getDeclaration(M, Intrinsic::stackguard);
+    return IRB.CreateCall(SG);
----------------
koriakin wrote:
> timshen wrote:
> > You may want to take a look at "getStackGuard()" in lib/CodeGen/StackProtector.cpp and possible factor it out (SupportsSelectionDAGSP is a bit weird, sorry), since it also takes care of IR form SSP.
> The functions look about the same.  The one in StackProtector emits a volatile load, but changing SafeStack to use one too shouldn't be much of a problem, right?  However, I now see I've introduced a problem in SafeStack - I'm calling insertSSPDeclarations on TL, which may be null (in which case getIRStackGuard isn't called either, ugh).  I'm not really sure how to deal with that - should we require a target machine when instantiating the SafeStack pass?  It would be best if we could just emit the stackguard intrinsic there and somone lower just took care of it...
I think the nullability of TL is a separate issue. If you don't have TL around then I don't know how may that happen, nor what to do.

If TL isn't nullptr, calling the factored out getStackGuard() in StackProtector.cpp seems to be good.

And as I said, I don't know any clean solution for insertSSPDeclarations. There exists very low level code (e.g. expandLoadStackGuard in X86InstrInfo.cpp) that is using the Value* form of the global variable.


Repository:
  rL LLVM

http://reviews.llvm.org/D19407





More information about the llvm-commits mailing list