On Tue, Apr 27, 2021, 23:56 Edward Catmur via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> On Tue, 27 Apr 2021 at 21:04, Андрей Некрашевич via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> > 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

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

It is attached to the exception object http://eel.is/c++draft/except.throw#3

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.