
Programmatic access to the call stack in C++ - kilimchoi
http://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/
======
forrestthewoods
I find it pretty annoying how often things are advertised as C++ but are Unix
specific. As someone who ships Windows + OS X + Linux I'm pretty biased
though.

Anyhow, there's pretty good support for stack traces on Win64. For 32 bit it's
less good. [https://msdn.microsoft.com/en-
us/library/windows/desktop/ms6...](https://msdn.microsoft.com/en-
us/library/windows/desktop/ms680650\(v=vs.85\).aspx)

~~~
nwmcsween
dwarf debug info is a part of x86_64 abi

------
mzs
Cool thanks for mentioning libunwind. I had used backtrace() and libexecinfo
where that was not available with not as good results.

~~~
eliben
libunwind is awesome. It uses the same information for its job that the actual
compiler uses for unwinding exceptions in C++, etc (DWARF .eh_frame & co).
It's also much more portable these days (I believe backtrace() is glibc-
specific). There are also remote unwinding capabilities I want to play with

~~~
cokernel_hacker
Darwin (iOS and Mac OS) have it too:
[https://developer.apple.com/library/mac/documentation/Darwin...](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/backtrace_symbols.3.html)

~~~
eliben
Ah cool.

But I'm fairly sure that these days os x uses libcxx which uses libunwind

~~~
boulos
I seem to recall them implementing the unwind _interface_ but with standard
rbp/ebp unwinding. As in
[http://www.opensource.apple.com/source/Libc/Libc-498.1.1/gen...](http://www.opensource.apple.com/source/Libc/Libc-498.1.1/gen/backtrace.c)
and
[http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/...](http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/thread_stack_pcs.c)

My biggest problem with "standard" libunwind is how slow it is compared to a
whole loop against the registers (which of course isn't reliable with -fomit-
frame-pointer). IIRC, the gcc's call to backtrace actually parses DWARF to
work around this (and thus is super slow).

