On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams
wrote:
I didn't mean it as a solution. As said, I was just looking for
an intro to the topic, so that I (and others) could
meaningfully contribute or at least understand the options.
I'll look up libunwind and, if that has enough info for me to
grok it, create a wiki page on the subject.
It is a horrible solution developed for the Itanium VLIW
architecture which is very sensitive to branching. IRRC it
basically works by looking at the return address on the stack,
then picking up stack frame information in a global table to
unwind. It is language agnostic and the language provides a
"personality function" to unwind correctly in a language
dependent manner...
AFAIK, C++ exceptions are copied from the stack to a special
memory region when unwinding to prevent the memory issues D
suffers from.
I agree that a fast unwind with stack pointer reset or multiple
return paths would be much better, but you need to rewrite the
backend to support it. That's the main issue... the "fast path"
argument is just a sorry excuse that literally means that
exceptions are avoided for common failures in C++. As a result
you get APIs that are nonuniform.
