On Wed, 28 Apr 2021 at 07:41, Antony Polukhin <antoshkka_at_[hidden]> wrote:

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

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