Fixed a typo Integirty -> Integrity

Thanks a lot for the review! No, I do not have commit access, please feel free to commit on my behalf.

Thanks for the comments! I've addressed them in the updated patch.

Addressed feedback by jfb:

Updated to include the cfe-commits list as a subscriber.

Updated to include the cfe-commits list as a subscriber.

Both dynamic and static leaks verifiers are great ideas! In practice, it might also be useful to have a pass that looks for all uses of known ways to leak the stack pointer in the IR, i.e., frameaddr-like intrinsics, gcroot, inline asm that accesses %rsp, etc. This wouldn't be as future proof as binary verifiers, but might be easier to implement and use.

Peter, thank you for helping with the patches! The updated patches also include minor bugfixes, cleanup and improved documentation. We also prepared a few more patches to submit separately, which enable applying SafeStack to shared libraries, support ucontext API and sigaltstack, and implement some platform-specific performance improvements.

Fixed symbol naming on Mac.

Simplified safestack public symbol names.

Added documentation for the no_safe_stack attribute. Simplified safestack public symbol names.

Simplified safestack public symbol names.

Added tests for the safestack runtime support library.

Added tests for attribute((no_safe_stack)).

Move mmap's #ifdef out of the functions to improve readability.

Added unittests for the -fsafe-stack and -fno-safe-stack options in clang and -fstack-protector 4 option in clang-cc1.

You can find the detailed changelog since the previous submission in our repo: https://github.com/cpi-llvm/compiler-rt/commits/safestack-r221153

You can find the detailed changelog since the previous submission in our repo: https://github.com/cpi-llvm/clang/commits/safestack-r221153

You can find the detailed changelog since the previous submission in our repo: https://github.com/cpi-llvm/llvm/commits/safestack-r221153

Addresses comments on the previous submission.

Addresses comments on the previous submission.

Addresses comments on the previous submission.

Yes, running SafeStack with opt would certainly simplify debugging.
However, we want to apply the SafeStack transformation as the very last
step before code generation, to make sure that it operate on the final
stack layout. Doing so earlier might prevent some other optimizations from
succeeding (as it e.g., complicates the alias analysis, breaks mem2reg
pass, etc.) or might force the SafeStack pass move more objects to the
unsafe stack than necessary (e.g., if the operations on such objects that
the SafeStack considered potentially unsafe are actually later optimized
away). In principle, in some pathological cases, it might even break
correctness, e.g., if the SafeStack decides to keep some object on the
normal stack, but the subsequent optimization or instrumentation passes add
potentially unsafe operations on such objects.

Hi David,