search for: unwind_resum

...a handler: it just rethrows the exception. This is not very interesting of course, but it's still a handler. Or do you mean something different when you talk of a handler? > and caches where it thinks it > is. That code (cleanup or whatever) is executed and ends by reaching > Unwind_Resume, which tries to resume at where it thinks the handler > is. I also don't understand this: why is Unwind_Resume looking at where the exception's handler is? The handler used for the caught exception should be irrelevant to it. It sounds like the unwinder thinks that the Unwind_Resum...

...; a catch-all! The unwinder works by doing a stack crawl to find a handler. Since we're telling it every eh-selector is a catch-all handler, it finds one immediately (that is not there) and caches where it thinks it is. That code (cleanup or whatever) is executed and ends by reaching Unwind_Resume, which tries to resume at where it thinks the handler is. Which is back at the same code from which we reached Unwind_Resume. This worked OK when we were caching the IP because the IP of the throw and Unwind_Resume call were different, but when caching the CFA they are the same, which co...

Hi Chris, > ... Claiming that a function has a > > catch-all handler when it does > > not causes the unwinder to go into a loop. this is the bit I don't understand. Why does it go into a loop? How can the unwinder possibly know that the original code did not have a catch-all, since we tell it which catches there are and we say: there is a catch-all! > > -

...te a possibly null cleanup, then resumes. > > I agree, and this is why I originally tried to get the desired effect > using cleanups. > >> The trouble is you can't simply copy that IR while inlining and >> expect >> things to still work, because the operation of Unwind_Resume depends >> on what stack frame it's in. I don't agree that the inlined version >> is correct IR. The 'invoke semantics' you're talking about are >> inextricably intertwined with _Unwind_Resume's semantics. > > The semantics of invoke are described...

Hi Dale, > No, I don't want to change the semantics of invoke, at least I don't > think so. > When inlining, I want the inlined throw to reach cleanup code as it > does. > But I want the Unwind_Resume call that ends the cleanup code to be > replaced with a control transfer to the handler (or cleanup) in the > calling > function, i.e. the inliner needs to know the semantics of Unwind_Resume. it seems to me that this is extremely tricky to do in general, though it is simpler if you su...

...%eh_ptr = tail call i8* @llvm.eh.exception( ) > %eh_select8 = tail call i32 (i8*, i8*, ...)* > @llvm.eh.selector.i32( i8* %eh_ptr, i8* bitcast (i32 (...)* > @__gxx_personality_v0 to i8*)) I wasn't advocating this; agree it is wrong. > tail call i32 (...)* @_Unwind_Resume( i8* %eh_ptr ) > unreachable > ... > } > > define i32 @main() { > entry: > invoke void @_Z1fv( ) > to label %somewhere2 unwind label %lpad2 > ... > lpad2: ; preds = %entry > %eh_ptr = tail call i8* @llvm.eh.exce...

...e throwing > function to execute a possibly null cleanup, then resumes. I agree, and this is why I originally tried to get the desired effect using cleanups. > The trouble is you can't simply copy that IR while inlining and expect > things to still work, because the operation of Unwind_Resume depends > on what stack frame it's in. I don't agree that the inlined version > is correct IR. The 'invoke semantics' you're talking about are > inextricably intertwined with _Unwind_Resume's semantics. The semantics of invoke are described in the LangRef...

On Dec 12, 2007, at 11:01 AM, Duncan Sands wrote: > Hi Dale, > >> No, I don't want to change the semantics of invoke, at least I don't >> think so. >> When inlining, I want the inlined throw to reach cleanup code as it >> does. >> But I want the Unwind_Resume call that ends the cleanup code to be >> replaced with a control transfer to the handler (or cleanup) in the >> calling >> function, i.e. the inliner needs to know the semantics of >> Unwind_Resume. > > it seems to me that this is extremely tricky to do in general,...

...to label %normal unwind label %unwind > > exit: ; preds = %unwind, %dtor > %1 = phi %0 [ %5, %unwind ], [ %6, %dtor ] > %2 = phi i8 [ 1, %unwind ], [ %7, %dtor ] > %3 = icmp eq i8 %2, 0 > br i1 %3, label %return, label %unwind_resume > > return: ; preds = %exit > ret void > > unwind_resume: ; preds = %exit > resume %0 %1 > > normal: ; preds = %entry > %4 = bitcast %item* %y...

On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: > On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote: [...] > This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the

...ve #include <cstdio> class A { public: A() {} ~A() {} }; void f() { A a; throw 5.0; } main() { try { f(); } catch(...) { printf("caught\n"); } } The IR for f correctly has the throw call reaching the landing pad, which cleans up 'a' and then calls Unwind_Resume. Inlining g into f naively copies this structure which is wrong; we do not want to call Unwind_Resume in this case because there is a real handler in the same function. See the code produced by gcc -O3. I think what you did is make this incorrect Unwind_Resume work (on your OS), but t...

...int main(int argc, char **argv) { try { throw argc; } catch(int i) { return i; } return 0; } However, it segfaults when I run it. I've attached the .s files generated by LLVM and GCC, but it looks as if LLVM isn't generating a gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is this what's causing the failure? Does anyone know how to get it to generate this section? Thanks! -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: t.gcc.s Type: application/octet-stream Size: 4259 bytes Desc: not available URL: <http://lis...

...have this project that I can't see how to boil down into a cut down illustration of the problem as it requires a large 3rd party library (ITK www.itk.org), and the problem is actually triggered in that library. But here is the problem: If you compile ITK and the program, it will segfault in _Unwind_resume at the end of a class method. If you build with GCC (4.6.1 in this case) the program passes all regression tests. In gdb, it's really difficult to see what's going on. For one thing it looks like CLang++ is rearranging code even if the -g flag is given -- the execution cursor jumps arou...

Hi Dale, > - Why was C++ claiming that every selector has a catch-all handler? this is easy: because the semantics of invoke require it. Yes, really. If unwinding reaches an invoke then control is required to jump to the unwind basic block. At first I thought this probably wouldn't matter - that it would be OK to not jump to the landing pad if the exception was not being caught by it -

...row argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a > gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is > this what's causing the failure? Does anyone know how to get it to > generate this section? does it segfault if you link using mainline g++? Where does the segfault occur - in the unwinder, or in the program itself (and if so, where)? Thanks, Duncan.

...throw argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a > gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is > this what's causing the failure? Does anyone know how to get it to > generate this section? The most obvious thing different is that gcc expects the return value of the throw (EDX) to be 1, while llvm expects it to be 2. Try changing the cmp to 2 at line 46 to cmp aga...

...quot;doIt: end\n"); } The code after the throw statement is unreachable. The last instruction of the finally block is a resume. LLVM now removes the last printf call and the epilogue code because it is all dead code. In fact the last instruction generated for this function is a call to the unwind_resume library function. Unfortunately Windows 64bit requires the epilogue code to perform the stack unwinding. In this special case it is not dead code but another form of metadata. See here: http://msdn.microsoft.com/en-us/library/8ydc79k6.aspx. Is there a simple way to always enforce the generat...

...ng? Thanks! Damien if (!RewindFunction) { LLVMContext &Ctx = Resumes[0]->getContext(); FunctionType *FTy = FunctionType::get(Type::getVoidTy(Ctx), Type::getInt8PtrTy(Ctx), false); const char *RewindName = TLI->getLibcallName(RTLIB::UNWIND_RESUME); RewindFunction = F->getParent()->getOrInsertFunction(RewindName, FTy); } ________________________________ This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside inf...

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

...ormal unwind label %unwind >> >> exit: ; preds = %unwind, %dtor >> %1 = phi %0 [ %5, %unwind ], [ %6, %dtor ] >> %2 = phi i8 [ 1, %unwind ], [ %7, %dtor ] >> %3 = icmp eq i8 %2, 0 >> br i1 %3, label %return, label %unwind_resume >> >> return: ; preds = %exit >> ret void >> >> unwind_resume: ; preds = %exit >> resume %0 %1 >> >> normal: ; preds = %entry...