Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-18 17:14:41

2016-12-18 20:26 GMT+03:00 Peter Dimov <lists_at_[hidden]>:
> 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.

Already.

> - ideally, both ought to be async safe, or as async safe as possible on the
> target architecture.

I'm trying to unify behavior rather than provoking people to write
unportable code. Both must be as async safe, if *all* the platforms
allow to do that.

> - there should be a low-level API that is async safe, and a high level API
> that is not necessarily such.

There's no way to get function location in async safe way onWindows.

> - macOS should be supported.

OK.

> - the library should not #include <windows.h>. The part of the Windows
> backend that needs <windows.h> should be a separately-compiled library.

I'd rather take the boost/winapi path.

> 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 );

That's doable. But how are you going to use it?

> // resolution
>
> void stracktrace_resolve_frame( stacktrace_frame address, char function[],
> size_t fnsize, char file[], size_t filesize, size_t & line );

What if the user wants only the function name?

> 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.

As today - it is unsafe. We may assume the safety, but there's no
guarantee. Moreover, I'm pretty sure that it is unsafe.

> On Mac OS X, stacktrace_capture can use ::backtrace and stacktrace_resolve
> can use the atos utility instead of addr2line.

glibc ::backtrace() implementation is not async-signal-safe. So
probably I will need to discover another way of doing that thing.

> https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/atos.1.html

-- 
Best regards,
Antony Polukhin