[LLVMdev] LLVM Exception Handling

[Nathan Jeffords]

On Sun, Sep 26, 2010 at 4:19 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 25 September 2010 23:46, Nathan Jeffords <blunted2night at gmail.com>
> wrote:
> > catch:
> >   %v = ptrtoint i8 * %x to i32
> >   %r = icmp eq i32 %v, 255
> >   br i1 %r, label %bad, label %worse
> > bad:
> >   ret i32 -1
> > worse:
> >   ret i32 -2
> > }
>
> If I understood correctly, you're trying to pass the clean-up flag
> through %x directly on the invoke call. But later avoid the
> eh.exception call, assuming that was in %x.
>
> The problem is that you're mixing two concepts: The exception
> structure contains information about the object that was thrown and
> not a "good" number. That's the role of the clean-up flag (in case the
> catch blocks can't deal with the exception) or the landing pads (that
> should reflect the return values the user asked for in their
> programs).
>
> It's the users role to tell what's good and what's not (return values
> included). the only thing you (compiler) can do is to explode
> prematurely in case you can't properly catch the error (ie. throw
> inside throw, throw inside delete, etc).
>

The argument to the unwind instruction is always an i8* pointer, which in
the case of dwarf exception handling would be the allocated exception
object. I did cheat for the example, but this also demonstrates that an
arbitrary value could be passed if using an LLVM specific exception handling
implementation like the setjmp/longjmp version provided by the LowerInvoke
pass.


>
> If that's the case, your implementation will not work for dwarf
> exceptions, and I wouldn't recommend having an *invoke* syntax for
> each type of exception handling mechanism.
>
> Other question: why are you passing untyped %x? I haven't seen any
> untyped variable in LLVM, so far, and I think it's good to be
> redundant in this case. That alone would have caught the mistake. If
> you need an i32 (for your bad/worse comparison), throwing i8* would
> have hinted that you crossed the concepts.
>
>
The syntax for the invoke instruction is a little misleading. %x is a value
that is being generated by the instruction, not passed to is. It is no
different in that regard as to say '%x = call @eh.exception ...'. Since you
don't specify the type in that type of assignment, I chose not to here
either.



>
> On a side note...
>
> Exception handling was designed by the devil himself. Part of the flow
> control is designed by the user (try/catch blocks, throw
> specifications), part of it is designed by the compiler, in exception
> tables (specific unwinding instructions and types), and part by the
> library writers (unwinding and personality routines). All that,
> decided in three different time frames, by three different kinds of
> developers, have to communicate perfectly in run time.
>
> It'd be very difficult for the compiler to optimize automatically
> without breaking run-time assumptions. All of that is controlled by
> different ABIs, that make sure all three universes are talking the
> same language. You can't change one without changing all the others...
>
>
I agree; this change is not attempting to change how exception handling
works, just provide a small change in how it is represented in the IR to
make it more direct. Especially for users not using gcc/dwarf exception
handling (I hope to attempt an SEH implementation)


> To be honest, I'm still surprised that it actually works at all! ;)
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>

Thanks for the feedback

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/8451d346/attachment.html>