4 ms·

Programmatic access to the call stack in C++

82 points by kilimchoi 11y ago

mzs 11y ago
Cool thanks for mentioning libunwind. I had used backtrace() and libexecinfo where that was not available with not as good results.
- chuckcode 11y ago
  gperftools also uses libunwind and does some nice timing and performance analysis for cpu and heap. https://code.google.com/p/gperftools/ https://code.google.com/p/gperftools/
- eliben 11y ago
  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 11y ago
    Darwin (iOS and Mac OS) have it too: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/backtrace_symbols.3.html https://developer.apple.com/library/mac/documentation/Darwin...
    - eliben 11y ago
      Ah cool. But I'm fairly sure that these days os x uses libcxx which uses libunwind
      - boulos 11y ago
        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/backtrace.c http://www.opensource.apple.com/source/Libc/Libc-498.1.1/gen... and http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/thread_stack_pcs.c http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/... 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).
  - mzs 11y ago
    Yes backtrace() and friends is a glibc thing, but libexecinfo tries to be compatible and portable. Back when I used backtrace(), that was about the best there was, and it was not that great really. I'm glad I know about libunwind now thanks to this post.
pg_is_a_butt 11y ago
this method will still leave out all the ways dynamic code might be created to call your method... you could run your tool, determine all the backtraces the tool could derive, make assumptions using that data, make changes using those assumptions, and then have your codebase completely break because of dependancies from dynamically generated code.
forrestthewoods 11y ago
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/ms680650(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- nwmcsween 11y ago
  dwarf debug info is a part of x86_64 abi

82 points by kilimchoi 11y ago

mzs 11y ago

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

chuckcode 11y ago
gperftools also uses libunwind and does some nice timing and performance analysis for cpu and heap. https://code.google.com/p/gperftools/ https://code.google.com/p/gperftools/
eliben 11y ago
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 11y ago
  Darwin (iOS and Mac OS) have it too: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/backtrace_symbols.3.html https://developer.apple.com/library/mac/documentation/Darwin...
  - eliben 11y ago
    Ah cool. But I'm fairly sure that these days os x uses libcxx which uses libunwind
    - boulos 11y ago
      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/backtrace.c http://www.opensource.apple.com/source/Libc/Libc-498.1.1/gen... and http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/thread_stack_pcs.c http://www.opensource.apple.com/source/Libc/Libc-825.25/gen/... 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).
- mzs 11y ago
  Yes backtrace() and friends is a glibc thing, but libexecinfo tries to be compatible and portable. Back when I used backtrace(), that was about the best there was, and it was not that great really. I'm glad I know about libunwind now thanks to this post.

pg_is_a_butt 11y ago

this method will still leave out all the ways dynamic code might be created to call your method... you could run your tool, determine all the backtraces the tool could derive, make assumptions using that data, make changes using those assumptions, and then have your codebase completely break because of dependancies from dynamically generated code.

forrestthewoods 11y ago

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/ms680650(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

nwmcsween 11y ago
dwarf debug info is a part of x86_64 abi