Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Peter Dimov (lists_at_[hidden])
Date: 2016-12-18 12:26:33


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/ManPages/man1/atos.1.html


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk