On Wednesday, 18 February 2015 at 08:13:35 UTC, Ola Fosheim
Grøstad wrote:
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.
Windows SEH maintains a per-thread linked list of exception
handlers, but the C++ runtime seems to install only one handler
at the start of every function and resorts to lookup tables if
there are multiply try{}s in the function.
If you want to avoid lookup tables, you can of course add/remove
catchers dynamically whenever you enter/leave a try block, that
would add a small cost to every try, but avoids the (larger)
table lookup cost on the catch.
