> Presumably this particular implementation won't work if libcxxabi is
statically linked
Yes, that's right. But as the paper says - `libsfe` is just a prototype to show that we can add `std::stacktrace::from_current_exception` without breaking ABI. Library does not pretend to be a release implementation.
There is some overhead in taking a stack trace, even if you defer symbol (and source location) resolution until it is used. Are you proposing that the runtime call backtrace / CaptureStackBackTrace on every throw?
Functions like _Unwind_Backtrace are already called during stack unwinding. Yes, the frame pointer has to be stored but that takes an order of magnitude less CPU time than:
* dynamic memory allocation for exception object
* recursive mutex locking and unlocking that is done for each frame
Only as far as is necessary to reach the selected handler, though; presumably the stacktrace associated with a caught exception would run all the way to thread entry? I suppose you could backtrace as far as the handler during unwinding, and splice on the rest of the stack when the user calls from_current_exception() or constructs the current exception_ptr.
Also there's a dynamic memory allocation, which is limited only by stack depth,
unlike with throwing an exception where it's limited to the size of the exception object. Is it OK to pay this on every throw?
Some platforms may implement exception handling without those overheads and storing a frame address may be noticeable. Because of that D2370R0 recommends a link time flag to disable traces. Getting empty std::stacktrace from the proposed from_current_exception() function is fine.
Will the stack trace be attached to std::exception_ptr?
In other words, storing an exception into std::exception_ptr, passing into another thread of execution, rethrowing it and printing its stacktrace outputs the stacktrace captured in the initial thread on throw.