DrCallstack: provide callstack walking and packing as a DR Extension

[derekbruening]

This is a longstanding feature request to take Dr. Memory's existing callstack walking code, which has many heuristics for stack scanning along with a compact storage scheme, and turn it into a general library that any DR client can use.

The original entry in the prior tracker:

From [email protected] on March 09, 2012 09:40:40

xref issue #822 another extension from the original discussion was DrCallstack: walking and packing callstacks, including md5 and crc32 checksums. again, this would stay within the drmemory codebase: simply build callstack.c as an Extension and perhaps tweak the interface a little if necessary but it shouldn't need much as its options, etc. are all already modular.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=823

[derekbruening]

From [email protected] on February 01, 2014 08:37:45

Reminder: make sure to document support for keeping unique callstacks in a
hashtable like drmem does for malloc callstacks.

We should also move -zero_retaddr into DrCallstack.
We'd need to include its auxiliary pieces:

• issue Dr.Memory light mode fail to clean return address from app stack #1371 : _SEH_epilog4
• issue Dr.Memory light mode fail to clean return address from app stack for handle test case #1374 (and issue APP CRASH (win8x86 calc under DrMem) chkstk stack zeroing breaking transparency #1405 ): chkstk
• issue Windows vs C heap mismatch (win8 VS2012 x64 handle test) #1278 (and issue -replace_malloc -leaks_only callstacks messed up for leaks and handle leaks #1217 , issue zero_stack() in exit_client_code() is a perf hit #1284 ): drwrap_replace_native_fini(), etc.

The last one we can't easily include: we'd have to document that those
using drwrap_replace_native may need to zero things?

[derekbruening]

DynamoRIO/dynamorio#2414 is the same request but in the DR tracker and maybe diverging if we want a BSD-licensed extension.

[derekbruening]

We'd want to improve win64 walking with #1222.

[derekbruening]

And we'd want to provide a way to use .eh_frame/.debug_frame: #2399. Even if that's too slow for Dr. Memory it is more accurate these days and is what most users would want. Even Dr. Memory is recently hitting cases that require just too much stack scanning and it may be time to re-evalute Dr. Memory's use of DWARF unwind info.