Date: Wed, 28 Apr 2021 13:22:26 +0300
On 4/28/21 1:21 PM, Andrey Semashev wrote:
> 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.
I meant "opt-out" in the sentence above. It should be an explicit opt-in.
> 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.
I meant "opt-out" in the sentence above. It should be an explicit opt-in.
Received on 2021-04-28 05:22:31