[LLVMdev] x86 unwind support

Kenneth Uildriks kennethuil at gmail.com
Sun Jul 19 08:18:47 PDT 2009


OK, I've read through http://www.llvm.org/docs/ExceptionHandling.html
several times now.

Let's see if I understand this...

1. Everywhere inside a "try" block, the C++ front-end emits "invoke"
instructions instead of "call" instructions.  Without any
transformations, this "invoke" instruction compiles down to assembly
code that doesn't seem to do anything different from a "call"
instruction.  Also, "unwind" compiles down to nothing.  However, every
function gets some DWARF info compiled into it by LLVM, and part of it
is information about the invoke site.

2. To throw an exception, call __cxa_allocate_exception to allocate an
exception object, and __cxa_throw to throw it.

3. Every function gets some DWARF info complied into it by LLVM.  The
__cxa_throw function uses it to find the function that issued the
"invoke" and find the "landing pads" and jump to the right landing pad
based on the exception type.

4. The landing pad uses exception-handling intrinsics to match the
exception type and to get the exception object.

The lowerinvoke pass adds SJLJ-based unwinding, which is a separate
mechanism based on GCC sjlj exception handling.

My proposed pass adds a lighter-weight setjmp/longjmp-style unwinding.

How do either of these prevent DWARF exception handling from working?
Would a landing pad expecting to get an exception object from the
exception intrinsics fail to get one in the case of an unwind and
crash?

Did I misunderstand anything I outlined above?

Is the exception-throwing function call expected to become an
intrinsic or an instruction in the future?  Will it replace unwind?

(Perhaps I should put all this aside and just have my compiler handle
my invoke/unwind logic instead of trying to use invoke/unwind
instructions.)

On Sat, Jul 18, 2009 at 3:04 PM, Duncan Sands<baldrick at free.fr> wrote:
> Hi Kenneth, this way of implementing unwind won't interact properly with
> dwarf exception handling.  That's rather bad.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>




More information about the llvm-dev mailing list