On 4/28/21 9:41 AM, Antony Polukhin via Std-Proposals wrote:
>
> On Tue, Apr 27, 2021, 23:56 Edward Catmur via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
>
> On Tue, 27 Apr 2021 at 21:04, Андрей Некрашевич via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto: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

Saving a single pointer is not enough to capture a stacktrace. A
captured stacktrace is supposed to be stable and not rely on the current
state of frames on the stack, which means the whole snapshot of
information related to frames need to be copied at the point of capture.
This is a dynamic amount of information, dependent on the number of
frames and the max depth you want to save, and it is definitely larger
than a pointer.

I'm firmly of an opinion that the stacktrace capturing must be an
explicit operation issued by the user at the throw site. It must not be
implicitly done on every throw. And no, making it an optional opt-in is
not acceptable either, as it will affect the existing code that has no
idea of this new feature.