2016-10-26 1:13 GMT+03:00 Gavin Lambert
On 26/10/2016 08:14, Antony Polukhin wrote:
Could it be move-only?
Yes, but that will make the situation worse :( Class stacktrace does not hold actual `frame` instances, it holds a raw pointers or some high-level stuff that has different size depending on the backtrace backend. If I make the `frame` class copyable, it will either * break the ability to disable stacktraces without recompilation; will not allow to change backends transparently * lead to nonintuitive situation, that `frame` is just a reference to actual frame data that is kept inside stcktrace class. So a copy of `frame` becomes invalid after the stacktrace destruction.
Not sure if this helps or hinders, but these are the things I would consider to be most important in a stacktrace library:
1. Capturing the current state/trace should be as fast as possible.
Already done. + stack capturing is noexcept. Thou not all the backends have great performance. I'll improve the docs by highlighting the performance differences for backends.
2. This captured context should be able to be copied/moved into an exception or into a container and passed to a different thread for later use. (It is reasonable to only be able to do so for the context as a whole, not individual frames, although it's also useful to be able to "trim" the captured context before storing it (eg. omit the first few frames which are inside stack-trace-capturing methods rather than places of interest).)
Already done. + copy constructor is noexcept.
3. In this secondary location it should be possible to symbolise the stack trace (ie. turn raw addresses into function/source/line info). And in particular this should be done only on such request, not at the original point of capture (to make that faster).
Already done for function names, source and line info will hopefully come soon.
4. It would be useful, though not essential, to have a serialisation format such that the context from #1 can be saved to a file and a separate utility on a separate machine can be used to do #3 (similar to addr2line, but better). It's reasonable to require that the original binaries and symbol files are available to perform the symbol decoding, and it's expected that the serialisation format would have to include not just the trace addresses but also the module load addresses, since they might have loaded in different locations than their binary headers specify, especially on machines with ASLR enabled.
That's interesting! I'll make it possible to have that functionality by adding an get_address() function to the frame class. I'll try to implement that and provide an example in docs soon. Great thanks!
(re: #1, I'm thinking in part of the ETfW sampling, which is able to capture stack traces from all threads every millisecond and every context switch, among other events, without noticeably slowing down even a high-performance application. Comes in surprisingly handy at times to have capturing that fast, even when doing it more ad hoc rather than sampling.)
Not sure that the library is meant for that: such functionality requires additional care, permissions and probably special compiler support. -- Best regards, Antony Polukhin