llvm dev - Jul 2009 - [LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

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
>

Hi,
> How do either of these prevent DWARF exception handling from working?
if you throw an exception using your proposed unwind implementation,
then it wouldn't be caught by dwarf catch/cleanup regions (eg: invoke).
> 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?
The landing pad would never be executed in the first place.  This
is rather bad, for example cleanups won't be run.
> (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.)
For the moment that is the best solution I think.

Ciao,

Duncan.

Hi,

Can I interject something at this point.

Can I suggest that invoke/unwind be renamed DWARF_invoke/DWARF_unwind to 
warn the unwary that if they want lightweight exception handling in 
their Python/ML/whatever implementation they should use some other method.

PS.
Kenneth, why don't you just use setjmp/longjmp directly.
Or, if you want, I can email you my lightweight versions if you want,

Mark.

Duncan Sands wrote:
> Hi,
> 
>> How do either of these prevent DWARF exception handling from working?
> 
> if you throw an exception using your proposed unwind implementation,
> then it wouldn't be caught by dwarf catch/cleanup regions (eg: invoke).
> 
>> 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?
> 
> The landing pad would never be executed in the first place.  This
> is rather bad, for example cleanups won't be run.
> 
>> (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.)
> 
> For the moment that is the best solution I think.
> 
> Ciao,
> 
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>