You can find the detailed changelog since the previous submission in our repo: https://github.com/cpi-llvm/compiler-rt/commits/safestack-r221153
================ Comment at: lib/safestack/safestack.cc:51 @@ +50,3 @@ + +// The unsafe stack pointer is stored in the TCB structure on these platforms +#if defined(__i386__) ---------------- theraven wrote: > kcc wrote: > > I might be missing something, but can't we just use TLS to store the > > second stack? > C11 TLS does not have a way of attaching destructors. C++11 does (although > the standard is undefined in the presence of shared library loading and > unloading, which makes it less useful), but does not have any way of ordering > the destruction. The main reason of putting the unsafe stack pointer in the tcb directly is performance: that way, the unsafe stack pointer can be loaded/stored with just one memory access. It's exactly the same optimization as the existing stack protector uses (see X86TargetLowering::getStackCookieLocation in X86ISelLowering.cpp:1925). Following David's suggestion, I will remove this optimization on Linux for now, until it can be properly implemented on the glibc side as well. I plan to only keep it on Darwin (where it seems to be cleaner, as I will explain in the comments). I will use TLS for unsafe_stack_(start|size|guard) on all platforms, as those are not performance critical in any way. http://reviews.llvm.org/D6096 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
