[LLVMdev] Exception handling question
junk at giantblob.com
Fri Jan 22 05:40:19 PST 2010
2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com>
> Yes. The issue here, as you pointed out, is that your personality function
> is not called at all.
> Even if you did nothing in the personality function, associated with the
> setup caused by
> llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be
> Your results are acting like either dwarf exception header info is not
> emitted (llvm::DwarfExceptionHandling = true;
> not executed could affect this), _Unwind_RaiseException(...) is not being
> called, or the default or another personality
> function (_gcc_personality_v0(...)) is called instead by the
> unwind infrastructure. Although you implied you
> dumped the exception headers and found your personality function, I can if
> you wish instead given you breaks for
> gbd so you can see if lvm.eh.selector is correctly prepping your
> personality function for eventual dwarf emission.
Yes - sorry I was unclear. I have pruned everything down to a pretty minimal
- LLVM 2.6 compiled from source
- A slightly modified version of Duncan's example ll assembly posted earlier
- A minimal personality function (just a call to fprintf()) in a separate C
file compiled with gcc-llvm
- A single C++ function in a third file that simply does "throw 1;" compiled
- I can definitely see the personality function in the exception headers and
it's definitely not being called.
- If i replace "throw 1" with "result = _Unwind_RaiseException" then result
is 5 - i.e. END_OF_STACK.
> On Jan 22, 2010, at 8:06, James Williams wrote:
> 2010/1/22 Duncan Sands <baldrick at free.fr>
>> 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
>> I'm pretty sure this doesn't matter. It seems to me more likely that the
>> exception object was not initialized properly.
> Hmm. I've tried a bunch of different ways of creating the exception
> including calling a C++ function that then does a throw. If I understand
> right, the personality function should still be offered the foreign
> exception so it has a chance to call cleanups?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev