I've read and re-read the LLVM exception handling doc, and there are a number of things that aren't clear to me. In the section describing llvm.eh.exception, it says "The backend replaces this intrinsic with the code that accesses the first argument of a call." I don't understand this sentence. A call to what? What is meant by 'accesses' - do you mean 'returns'? In the paragraph that describes llvm.eh.selector, it says "The first argument is the reference to the exception structure.", but later down it says "To express this in LLVM code the landing pad will call llvm.eh.selector. The arguments are the length of the filter expression (the number of type infos plus one) ...". This seems contradictory. If I am calling the _Unwind_ functions directly, do I need to use any of the llvm.eh.* functions? Can I just use invoke and write my own landing pad? How do you handle throwing an exception with a catch handler in the same function? Invoke won't work since it assumes that the exception is being thrown in a subroutine. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081223/dc181e7e/attachment.html>
Talin wrote:> I've read and re-read the LLVM exception handling doc, and there are a > number of things that aren't clear to me. > > In the section describing llvm.eh.exception, it says "The backend > replaces this intrinsic with the code that accesses the first argument > of a call." I don't understand this sentence. A call to what? What is > meant by 'accesses' - do you mean 'returns'? > > In the paragraph that describes llvm.eh.selector, it says "The first > argument is the reference to the exception structure.", but later down > it says "To express this in LLVM code the landing pad will call > llvm.eh.selector. The arguments are the length of the filter > expression (the number of type infos plus one) ...". This seems > contradictory. > > If I am calling the _Unwind_ functions directly, do I need to use any > of the llvm.eh.* functions?That's the only question I can answer :) Yes you need the llvm.eh.* functions even with the _Unwind_* functions and __cxa_throw. The llvm.eh.* functions allow the llvm code generator to produce dwarf exception tables. I don't know why the initial developers of exception handling in LLVM didn't use the unwind destination of an invoke instruction.> Can I just use invoke and write my own landing pad? > > How do you handle throwing an exception with a catch handler in the > same function?You'd need to do that by hand. Making an exceplicit __cxa_throw call in the llvm code.> Invoke won't work since it assumes that the exception is being thrown > in a subroutine. > > -- > -- Talin > > ------------------------------------------------------------------------ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi Talin,> I've read and re-read the LLVM exception handling doc, and there are a > number of things that aren't clear to me.I agree that this document is rather hard to read. I've committed some changes to try and answer your questions.> If I am calling the _Unwind_ functions directly, do I need to use any of the > llvm.eh.* functions? Can I just use invoke and write my own landing pad?Currently you need to use llvm.eh.selector (and thus llvm.eh.exception) in order to specify a personality function. Try using 0 as the third argument. I have a plan to eliminate this problem.> How do you handle throwing an exception with a catch handler in the same > function? Invoke won't work since it assumes that the exception is being > thrown in a subroutine.It is thrown in a subroutine, for example in _Unwind_RaiseException. Ciao, Duncan.