similar to: [LLVMdev] How to code catch-all in the new exception handling scheme?

On Sep 25, 2011, at 1:02 AM, Duncan Sands wrote: > Hi Talin, > >> I'm looking at the docs, and while it refers to a "catch-all" clause, > > hopefully Bill will get rid of the first reference to "catch-all" since > that section is inaccurate. > I *think* this is now correct. Please check. :) > it doesn't >> describe how to construct

On Sep 27, 2011, at 4:58 AM, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :) >

Hi Talin, > I'm looking at the docs, and while it refers to a "catch-all" clause, hopefully Bill will get rid of the first reference to "catch-all" since that section is inaccurate. it doesn't > describe how to construct one. There is in general no such thing as a catch-all: it depends on the personality function (i.e. the language), and, for example, the

Hi Bill, >>> I'm looking at the docs, and while it refers to a "catch-all" clause, >> >> hopefully Bill will get rid of the first reference to "catch-all" since >> that section is inaccurate. >> > I *think* this is now correct. Please check. :) I still have some niggles: The unwinder delegates the decision of whether to stop in a

Hi Bill, >> The unwinder delegates the decision of whether to stop in a call frame to >> that call frame's language-specific personality function. Not all personality >> functions guarantee that they will stop to perform cleanups. I was talking about who decides what to do if there are only cleanups all the way up the stack (in C++ the program is terminated without

Hi Duncan, On Sep 27, 2011, at 7:58, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :)

On 01/11/2012 02:37, Duncan Sands wrote: >> 1. What happens when actual exception type isn't listed in catch or >> filter clauses? Does it still return the corresponding structure like if >> it was listed? Or behavior is undefined? > if it doesn't match a clause then the exception continues to be unwound. > Note that you can match a catch clause without being equal

Duncan Sands wrote: > Hi Talin, > >> So I tried what you suggested, and it just gives me a bus error: >> >> %eh_select34 = call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32 ( >> i8* %eh_ptr, >> i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* >> @__gcc_personality_v0 to i8*), >>

Hi Talin, if you change @throwSomething so that it prints a message if the _Unwind_RaiseException call returns, then you will see that it does in fact return. define internal fastcc void @throwSomething() { entry: %throwable = malloc %Throwable call fastcc void @Throwable.construct(%Throwable* %throwable) %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

> > What? Yet another EH proposal?! This one is different from the > others in that > I'm planning to start implementing this shortly. But I want your > feedback! I've > all ready gotten a lot of feedback from Chris, John, Jim, Eric, and > many others. > Now is your turn! > > Please read this proposal and send me your comments, suggestions, > and

I'm having trouble understanding the value in the way exceptions are handled on Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads.

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: > I'm pointing out that if the invoke instruction > is removed and catch information is attached to entire basic blocks, then if no > care is taken then it is perfectly possible to use %x before it is defined as > explained in my previous email, blowing up the entire LLVM system. Clearly the > solution is to not allow this by not

Chris, it is goodness that the LandingpadInst will be pinned to the beginning of a BasicBlock,... except for the possibility of PHINode instructions that _must_ come even earlier.?. I can't exactly put my finger on what's going to go wrong with this, but it sure smells fishy... my current understanding is that the LandingpadInst will "define" some hard

Hi Peter, Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path.

On Dec 1, 2010, at 12:10 AM, John McCall wrote: > On Nov 30, 2010, at 11:04 PM, Bill Wendling wrote: >> • A landing pad must have exactly one dispatch instruction associated with it, >> and it must dominate that instruction. > > Okay, but how do we find it? > We can modify the dispatch to point back to the landing pad it's associated with. Something like: lpad:

On 1 December 2010 07:04, Bill Wendling <wendling at apple.com> wrote: > The unwind edge from an invoke instruction jumps to a landing pad. That landing pad contains code which performs optional cleanups, and then determines which catch handler to call (if any). If no catch handlers are applicable, the exception resumes propagation either to the next enclosing region or out of the

On Dec 1, 2010, at 1:14 AM, John McCall wrote: > On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote: > >> On 01.12.2010 09:25, John McCall wrote: >>> >>> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad. If that block is then deleted, we'd lose information about what's supposed to unwind there.

I have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm