[LLVMdev] Getting exceptions to work?

[Talin]

Well that clears up a little bit of the mystery - thanks for doing that
research.
I recognize the problem with runtime libraries for LLVM. I am in fact
writing a generic runtime library as part of the garbage collector work I am
doing - it uses policy-based templates so that things like the threading
model, atomic operations and error reporting can all be replaced by the host
environment as needed.

That being said, my immediate problem is still getting exceptions to work.

The biggest problem that I foresee with writing my own personality function
is dealing with all of the different platforms. Both LLVM and glibc isolate
me to some extent from platform idiosyncracies, meaning that I can for the
most part code against a platform-agnostic API and not worry about it.
However, the innards of glibc are no doubt radically different between
platforms, which will bring me a world of pain if I attempt to replace parts
of it.

On the other hand, at some point I was going to have to do this anyway,
given that I wanted to support compiling under MSVC as well as GCC
eventually. I feel that LLVM relies too heavily on functionality provided by
glibc, but I recognize that for most of the people working on it, that
option makes the most sense and meets their needs.

I don't actually think that LLVM needs its own standard personality function
per se. I think what it needs is a few additional intrinsics that will allow
someone like me to write a personality function. An example would be
intrinsics that wrap around the various libunwind methods, but which hide
the specific platform details like register numbers and such.

How complex do you think a standard personality function would likely be?
This is kind of hard for me to guess, since I don't quite understand the
division of labor between the personality function and the landing pad (I
get the impression its flexible).

I can think of several ways in which a personality function might work:

1) The personality function examines the type of the exception object and
determines what label to branch to in the function containing the handler.
The biggest problem with this is that there's no way for the personality
function to take a reference to a label at the IR level.

2) The personality function examines the type of the exception object, and
returns an integer code telling the landing pad where to branch to. The
landing pad does a switch instruction and branches to the correct label. The
problem here is that passing values between the personality function and the
landing pad cannot be done at the IR level without knowing intimate details
about the platform.

3) The personality function merely returns true or false, indicating an
exception was caught or not - it's the landing pad's responsibility to
examine the exception type and branch accordingly. This type of personality
function would be relatively simple (if it worked) and completely generic.
At the same time, however, it is potentially the least efficient, since it
cannot make use of any of the jump table information generated by the
compiler, nor can it determine if the exception was in fact caught - it has
to assume that the exception was always caught, and then if the landing pad
later determines that there was no catch clause for that particular
exception type, then it has to rethrow it. (Note, I have no idea whether or
not either of these issues are in any way significant, since I don't know
what kind of code the compiler generates.)

On Thu, May 21, 2009 at 1:16 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Talin, if you change @throwSomething so that it prints a message
> if the _Unwind_RaiseException call returns, then you will see that
> it does in fact return.
>
> define internal fastcc void @throwSomething() {
> entry:
>         %throwable = malloc %Throwable
>         call fastcc void @Throwable.construct(%Throwable* %throwable)
>         %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1
>         call void @print(i8* bitcast ([6 x i8]* @str_throw to i8 *))
>         %throw = call i32 @_Unwind_RaiseException(%UnwindInfo* %unwindInfo)
>         call void @print(i8* bitcast ([6 x i8]* @str_abort to i8 *))
>         ret void
> }
>
> This is because it unwound the stack without finding any exception
> handlers.  It doesn't consider your exception handler to be a handler
> because it is registered as a "cleanup" which apparently doesn't count.
> (To force cleanups to be run in this situation you have to call the gcc
> forced unwind routine after calling Unwind_RaiseException).
>
> Of course you would probably like to have your handler be considered a
> real handler.  Sadly you can't use __gcc_personality_v0 for this: it
> only handles cleanups, and if it sees something else (eg: if you specify
> a catch-all in the selector) then it tells the unwinder to keep on
> unwinding, which is not what you want.
>
> So indeed you either need to write your own personality routine or use
> a more powerful personality function like the C++ personality, and use
> an eh.selector call to specify a catch-all (use null for this).
>
> In order to get correct invoke semantics, LLVM really needs its own
> personality function.  The problem is that LLVM doesn't have its own
> runtime library like libgcc.  This could be overcome by outputting the
> LLVM personality into each assembler file that needs it, with weak
> linkage so that multiple copies get collapsed to one at link time.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090521/e1ea2279/attachment.html>