[LLVMdev] Exception handling question

Garrison Venn gvenn.cfe.dev at gmail.com
Fri Jan 22 04:54:54 PST 2010


Ah! I forgot to mention I'm doing my tests with 2.7, NOT 2.6; also on OS X 10.6.2.

Garrison

On Jan 22, 2010, at 7:44, Garrison Venn wrote:

> Hey Duncan,
> 
> Yup, you are correct. Just tested to make sure. Invoking _Unwind_RaiseException(...) directly still sets up
> personality function (and calls it during exception search/cleanup), in corresponding frame headers for frame 
> containing invoke. Well ... ok, at least in a JIT execution environment. :-)
> 
> I thought maybe __gcc_personality_v0(...) was being called instead.
> 
> However, I also just tested with a garbage exception (offset exception ptr by 1000), being passed in to _Unwind_RaiseException(...), 
> with  the result that the personality function was still called with the cleanup landing pad correctly found. This personality ignored the 
> exception pointer. So I don't believe the problem is with the exception data since his personality function is not invoked. 
> 
> I would test the code directly but I don't yet have non-JIT experience with LLVM.
> 
> Garrison
> 
> On Jan 22, 2010, at 6:51, Duncan Sands wrote:
> 
>> Hi Garrison,
>> 
>>> %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* @_Unwind_RaiseException to i8* (...)*)(i64* %6)
>>>         to label %8 unwind label %.finally_pad  ; <i8*> [#uses=0]
>>> I am not sure this is going to work, at least from the way I've played with the system. In my examples the _Unwind_RaiseException(...) is called from a frame (function) called via
>>> the invoke instruction, not from a frame that contains the invoke instruction.
>> 
>> I'm pretty sure this doesn't matter.  It seems to me more likely that the
>> exception object was not initialized properly.
>> 
>> Ciao,
>> 
>> Duncan.
> 





More information about the llvm-dev mailing list