After this discussion, I can suggest the following changes to the library: - the part that captures a stack trace and the part that resolves it to function/file/line should be separate, and usable without each other. - ideally, both ought to be async safe, or as async safe as possible on the target architecture. - there should be a low-level API that is async safe, and a high level API that is not necessarily such. - macOS should be supported. - the library should not #include <windows.h>. The part of the Windows backend that needs <windows.h> should be a separately-compiled library. What I can suggest as a low-level API is: // capture typedef void (*stacktrace_frame)(); // a bit on the pedantic side, but why not size_t stacktrace_capture( stacktrace_frame buffer[], size_t size ); // resolution void stracktrace_resolve_frame( stacktrace_frame address, char function[], size_t fnsize, char file[], size_t filesize, size_t & line ); typedef void (*stacktrace_resolve_callback)( stacktrace_frame address, char const * function, char const * file, size_t line ); void stacktrace_resolve( stacktrace_frame const[] trace, size_t size, char function[], size_t fnsize, char file[], size_t filesize, stacktrace_resolve_callback callback ); On Windows, I see stacktrace_capture as header-only and async-safe, and stacktrace_resolve as separately compiled and maybe-mostly-safe, as today. On Mac OS X, stacktrace_capture can use ::backtrace and stacktrace_resolve can use the atos utility instead of addr2line. https://developer.apple.com/legacy/library/documentation/Darwin/Reference/Ma...