[LLVMdev] trouble understanding value in dwarf exception mechanism

[Renato Golin]

On 25 April 2013 06:38, edA-qa mort-ora-y <eda-qa at disemia.com> wrote:

> I'm having trouble understanding a few points. I would like to
> understand since I have exceptions in my language as well and want to
> make effective use of the model.
>

Hi,

You probably got there, but just reiterating: LLVM EH is not modelled with
only C++ exceptions in mind, so some things will look redundant for C++,
but they could not be for other languages. For instance, C++ can only have
one exception, Ada can have as many as you like, and you have to express
both on the same IR language, possibly both styles on the same module!

But also, the IR has to be generic AND efficient, so having more
information on the IR than needed at a lower level might mean that you'll
have better ways to prune stuff at all levels on all EH styles.



1. The way basic blocks come together often means you can have embedded
> try/catch handlers without an intervening function call. You can't have
> multiple landingpads without an intervening invoke thus one block needs
> to branch/include the other handler. This appears to result in the need
> to check the types of exceptions in the landingpad. This seems wasteful
> to check the types in both the personality and the landingpad.
>

There are two ways to get to landing pads: when an exception is thrown and
when you're unwinding. On the first case, you go straight to the right
landing pad and it looks a bit redundant, but on the second case, the type
of the exception can be anything, so the personality (or whatever will scan
the landing table) has to go over all types, and you have to have types
that bail, types that continue and types that are treated here and now.

Why not leave all to the personality, you ask down there: because it can
take a considerable amount of time to go all the way to runtime library
code and back, just to go to the right place. Compilers can make that a
jump with a very small immediate instead.



2. Cleanup landingpads, in the general case, will need to call
> functions. Not knowing what is in these functions one must assume they
> could in turn have their own exception flow: they have a try/catch but
> don't allow exceptions to escape. The ABI mechanism though seems like
> only one exception at a time can be in progress. This would mean that
> cleanup code would have to register as catch handlers and rethrow the
> exception -- they cannot be "cleanup" routines according to the standard.
>

The runtime exception library, at least in C++, has THE exception object
allocated and freed, so if you try to throw another object while one is
being handled, it'll detect and call terminate() in the run time code, not
clean ups, not landing pads, not user code. This is a not-so-hidden
contract[1] between user code, landing pads and the runtime library that
has to be followed, and why it's so hard to implement (and test) exception
handling.

cheers,
--renato

[1] http://mentorembedded.github.io/cxx-abi/abi-eh.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130425/7887d792/attachment.html>