implement shadow callstack and evaluate perf

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on December 20, 2011 10:57:37_

What is the problem to solve? Why is it important? Provide some context for those unfamiliar with the details of the system. We would like to use faster app builds for better performance. But while we can disable inlining and FPO in cl, there's no flag to disable tailcalls, so we can still end up with missing frames, cause suppressions not to match and confusing developers. Also, while most system libraries on Windows are not built with FPO, we would like to be able to handle those that are. And ideally if we could handle an app built w/ full opts including inlining and FPO we'd like best-effort callstacks to be sufficient, though we're not willing to give up much perf to get that. What are the possible approaches to solving the problem? Xref issue #703 , issue #711 , issue #557 . This issue covers implementing a shadow callstack and measuring the perf hit. Issue 703 suggests using shadow callstack for malloc-intensive apps (many callstacks) and callstack walking for all other apps. We could also have runtime control (if we can't dynamically detect an app with FPO) so a user building with FPO can get callstacks (at a perf hit that in fact might outweigh the benefit of FPO: but there would still be the advantage of not having a separate build, modulo uninit false pos from opts). Which approach is being taken and why? First, implement and measure. Then make some decisions on when to use it. Any interesting details or challenges of the implementation? Fairly straightforward. Implemented already in many other tools. Longjmp, SEH, etc. need to be handled, usually by storing app sp.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=724_