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 called. 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. Garrison 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 instruction. > > 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? > > > Ciao, > > Duncan. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/56a6bb17/attachment.html>
Hi Garrison,> 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 called.this is not correct. Unwind_RaiseException will just exit without unwinding the stack if all personality functions return _URC_CONTINUE_UNWIND. Ciao, Duncan.
Hi Duncan, Yes, but the personality function will get called in order for it to return _URC_CONTINUE_UNWIND. When I said "it", I meant the personality function in its search phase not the cleanup/handler phase. I believe, if I understand correctly, Jame's personality function is not being called during the search phase. If this is not case, and his personality function is called during the search phase, then as you indicated earlier, this is easy to solve. Garrison On Jan 22, 2010, at 8:29, Duncan Sands wrote:> Hi Garrison, > >> 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 called. > > this is not correct. Unwind_RaiseException will just exit without unwinding > the stack if all personality functions return _URC_CONTINUE_UNWIND. > > Ciao, > > Duncan.
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 > called. > 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 test: - 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 with g++-llvm - 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. -- James> > Garrison > > 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 >>> instruction. >>> >> >> 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? > > >> Ciao, >> >> Duncan. >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/c1da4c0a/attachment.html>
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 > called. > 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. > > It looks like __gxx_personality_v0 is getting called at least once but Imight expect that to tear down the frame of the C++ test function calling throw? It then disappears into std::terminate() and the aborts. If there is some sane way I can debug this it would be really handy so if you can tell me some good spots to set breakpoints I'd be grateful. As it is I'm stepping through reams of unfamiliar assembly with little clue what's going on. -- James> Garrison > > 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 >>> instruction. >>> >> >> 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? > > >> Ciao, >> >> Duncan. >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/3b3f491c/attachment.html>
Hi James,> Yes - sorry I was unclear. I have pruned everything down to a pretty > minimal test: > - 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 with g++-llvm > - 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.want to send us your testcase code? Then we can give it a whirl. Ciao, Duncan.
In 2.6 (which I have not checked to see if any updates exist for the release): - line 3992 in SelectionDAGBuild.cpp, in function: const char *SelectionDAGLowering::visitIntrinsicCall(CallInst &I, unsigned Intrinsic) This is is beginning of the IR Function to MachineFunction lowering for eh_selector_X - llvm::AddCatchInfo for function: void AddCatchInfo(CallInst &I, MachineModuleInfo *MMI, MachineBasicBlock *MBB) in SelectionDAGBuild.cpp This is where the arguments to llvm.eh.selector.X are handled during above lowering. Note: I have never tested with 2.6 so I don't know what the possible issues are for this version. In 2.7: - llvm::SelectionDAGBuilder::visitIntrinsicCall at source: case eh_selector: This is is beginning of the IR Function to MachineFunction lowering for eh_selector - llvm::AddCatchInfo for function: void AddCatchInfo(CallInst &I, MachineModuleInfo *MMI, MachineBasicBlock *MBB) in FunctionLoweringInfo.cpp This is where the arguments to llvm.eh.selector are handled during above lowering. Hope this helps Garrison On Jan 22, 2010, at 8:55, James Williams wrote:> > > 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 called. > 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. > > It looks like __gxx_personality_v0 is getting called at least once but I might expect that to tear down the frame of the C++ test function calling throw? It then disappears into std::terminate() and the aborts. > > If there is some sane way I can debug this it would be really handy so if you can tell me some good spots to set breakpoints I'd be grateful. As it is I'm stepping through reams of unfamiliar assembly with little clue what's going on. > > -- James > > Garrison > > 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 instruction. >> >> 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? >> >> >> Ciao, >> >> Duncan. >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/d2509f5d/attachment.html>