Investigate using C++ exception handling ABI to catch panics about nballerina HOT 7 OPEN

This is a good series of blog posts on how C++ exception handling works:

https://monkeywritescode.blogspot.com/p/c-exceptions-under-hood.html

C++ ABI is here:

https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html

from nballerina.

We are going to do #6 initially. This would be at a later stage, when we implement trap. But it might be worth thinking about now, since we are spending time on panics.

@KavinduZoysa What do you think?

from nballerina.

We are going to do #6 initially. This would be at a later stage, when we implement trap. But it might be worth thinking about now, since we are spending time on panics.

@KavinduZoysa What do you think?

Yes @jclark, I also agree with that, I will look into this.

from nballerina.

So this is sort of what we were doing before we started looking into backtrace.

to quote llvm-libunwind doc:

The unwinder has two levels of API. The high level APIs are the Unwind* functions which implement functionality required by cxa* exception functions. The low level APIs are the unw* functions which are an interface defined by the old HP libunwind project.

We were looking at the layer below _cxa* functions. One concern with relaying on higher level _cxa* function is that we'll have to ship libcxxabi. We were able to get the cross language unwinding working even with C. So I don't see this as a strong deciding factor for picking C++.

from nballerina.

This is an interesting doc from Herb Sutter on problems with exception C++ model

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Summary is here

This proposal aims to marry the best of exceptions and error codes: to allow a function to declare that it throws values of a statically known type, which can then be implemented exactly as efficiently as a return value.
Throwing such values behaves as-if the function returned union{R;E;}+bool where on success the function re- turns the normal return value R and on error the function returns the error value type E, both in the same return channel including using the same registers. The discriminant can use an unused CPU flag or a register.

Makes me wonder whether we should consider a strategy where return (for non-external functions) at the LLVM level is a boolean + a union of the abnormal error value and the normal return value. In that case, the problem turns into constructing a representation of the stacktrace that we can store in an error value to be printed out later.

from nballerina.

@manuranga and I are talking about the same thing, which is the base API defined in the Itanium C++ ABI doc:

https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-abi

from nballerina.

This is a brief summary of how the exceptions are handled in C++.

When an exception is thrown, it will call 2 c++ ABIs(__cxa_allocate_exception and __cxa_throw). Then __cxa_throw calls a couple of _Unwind_ methods to iterate through each stack to find the correct catch. If the correct catch was found, the instruction pointer is set to that place. All pieces of information needed to unwind will be kept under CFI(Call Frame Information). _Unwind_ methods use this CFI to iterate over the stack. To find the correct stack frame there is a function called __gxx_personality_v0. All the information related to exceptions(Type of exception, location of try/catch blocks, where to land) are defined under LSDA(Language-specific Data Area). The __gxx_personality_v0 should have the capability to read LSDA and check whether the given exception can be handled. The __gxx_personality_v0 is called for each stack frame.

I am currently working on investigating how this knowledge can be applied to implement ballerina trap/panic

from nballerina.