On Thu, 29 Apr 2021 at 19:13, Antony Polukhin <antoshkka@gmail.com> wrote:
On Thu, Apr 29, 2021, 20:01 Edward Catmur via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Thu, 29 Apr 2021 at 17:46, Andrey Semashev via Std-Proposals <std-proposals@lists.isocpp.org> 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.