On Thu, 29 Apr 2021 at 19:13, Antony Polukhin <antoshkka_at_[hidden]> wrote:

> On Thu, Apr 29, 2021, 20:01 Edward Catmur via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Thu, 29 Apr 2021 at 17:46, Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On 4/29/21 7:32 PM, Edward Catmur wrote:
>>> > It works in the most performance-sensitive case.
>>>
>>> No, it doesn't. It only works in your toy example where you call
>>> std::current_exception_stacktrace directly from the catch block and
>>> nothing else. This breaks in practically any other case that is even
>>> remotely close to anything real-world, where you do something useful in
>>> the exception handler that involves a cross-TU call. No, that doesn't
>>> sound like "works" to me, sorry.
>>>
>>
>> I may have been unclear. The logic is that the compiler sets the flag on
>> the handler to request stacktrace unless it can prove that the catch block
>> does not call anything that might require it.
>>
>
> Unfortunately compilers do not optimize exceptions even in very trivial
> cases https://godbolt.org/z/TKEjTfs1o
>

Well, absolutely - unless libgcc is compiled LTO and statically linked,
there's no way for the compiler to know what __cxa_throw et al are going to
do! Your LD_PRELOAD hooks the exception handling machinery to take a
stacktrace and then rtld_next; someone else's LD_PRELOAD could do something
else entirely.

We are planning to write a benchmark to see, how the stacktraces affect
> performance of exceptions:
> * if the effect is not noticeable - stick to the current design
> * otherwise - provide a
> std::this_thread::capture_stacktraces_on_throw(bool) function to enable the
> proposed functionality, that would be disabled by default
>

Ah, that's a sensible compromise.