2010/1/22 James Williams <junk at giantblob.com>> > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> I get the expected output (after changing i32 @llvm.eh.selector() to i64 >>> llvm.eh.selector.i64()) >>> >> >> in top-of-tree, llvm.eh.selector.i64 has been removed (though bitcode will >> autoupgrade) and there is only i32 @llvm.eh.selector(), which is why my >> example >> was written this way. >> > OK. I understand. > > Thanks again for the help. > -- James >Sorry. I think I was being very stupid. It looks like I was reading the tables wrong and the eh tables are probably actually correct for all my tests. I didn't realise the personality function went in a separate shared entry. I'm still not sure why it's not getting called by _Unwind_RaiseException but I don't think it's due to any problem with LLVM eh table output -- James> >> Ciao, >> >> Duncan. >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/3e0ae409/attachment.html>
Hi James,
Looking at:
%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.
Garrison
On Jan 22, 2010, at 6:09, James Williams wrote:
>
>
> 2010/1/22 James Williams <junk at giantblob.com>
>
>
> 2010/1/22 Duncan Sands <baldrick at free.fr>
> Hi James,
>
>
> I get the expected output (after changing i32 @llvm.eh.selector() to i64
llvm.eh.selector.i64())
>
> in top-of-tree, llvm.eh.selector.i64 has been removed (though bitcode will
> autoupgrade) and there is only i32 @llvm.eh.selector(), which is why my
example
> was written this way.
> OK. I understand.
>
> Thanks again for the help.
> -- James
> Sorry. I think I was being very stupid. It looks like I was reading the
tables wrong and the eh tables are probably actually correct for all my tests. I
didn't realise the personality function went in a separate shared entry.
I'm still not sure why it's not getting called by _Unwind_RaiseException
but I don't think it's due to any problem with LLVM eh table output
>
> -- James
>
>
> Ciao,
>
> Duncan.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/29a0a481/attachment.html>
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.
2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com>> Hi James, > > Looking at: > > %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. > > Garrison >Hi, Thanks but I've also tried calling both a separate C function that then calls _Unwind_RaiseException and also a C++ function that throws an integer with the same results. I've also just tried running the example code posted earlier by Duncan and I find that doesn't reach the landing pad either if g() is replaced with a C++ function containing "throw 1". I'm building LLVM from svn head now and I'll retry Dunan's example against that. -- James BTW: I found the exception handling docs on the wiki very helpful> > On Jan 22, 2010, at 6:09, James Williams wrote: > > > > 2010/1/22 James Williams <junk at giantblob.com> > >> >> >> 2010/1/22 Duncan Sands <baldrick at free.fr> >> >>> Hi James, >>> >>> >>> I get the expected output (after changing i32 @llvm.eh.selector() to i64 >>>> llvm.eh.selector.i64()) >>>> >>> >>> in top-of-tree, llvm.eh.selector.i64 has been removed (though bitcode >>> will >>> autoupgrade) and there is only i32 @llvm.eh.selector(), which is why my >>> example >>> was written this way. >>> >> OK. I understand. >> >> Thanks again for the help. >> -- James >> > Sorry. I think I was being very stupid. It looks like I was reading the > tables wrong and the eh tables are probably actually correct for all my > tests. I didn't realise the personality function went in a separate shared > entry. I'm still not sure why it's not getting called by > _Unwind_RaiseException but I don't think it's due to any problem with LLVM > eh table output > > -- James > > >> >>> Ciao, >>> >>> Duncan. >>> >>> >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/97884374/attachment.html>