similar to: [LLVMdev] Darwin vs exceptions

On Dec 7, 2007, at 4:40 PM, Dale Johannesen wrote: > So I couldn't get exceptions to work on PPC darwin. After much > digging and confusion, there seem > to be two separate issues. Ok. > 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 >

Hi Dale, > > 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! > > The unwinder works by doing a stack crawl to find a handler. Since > we're telling it

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! > > -

On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote: > Hi Dale, > >> #include <cstdio> >> class A { >> public: >> A() {} >> ~A() {} >> }; >> void f() { >> A a; >> throw 5.0; >> } >> main() { >> try { >> f(); >> } catch(...) { printf("caught\n"); } >> } > > this example

Hi Dale, > > ... Suppose we don't artificially add catch-alls to > > selectors. Then > > the above example compiles to: > > ... > I wasn't advocating this; agree it is wrong. it's maybe not as wrong as it seems since having an empty selector is equivalent to having a cleanup (IIRC) :) > > ... If you force a "cleanup" by changing the

On Dec 8, 2007, at 12:51 AM, Duncan Sands wrote: > 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

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that

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 -

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > 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

Hi Dale, > #include <cstdio> > class A { > public: > A() {} > ~A() {} > }; > void f() { > A a; > throw 5.0; > } > main() { > try { > f(); > } catch(...) { printf("caught\n"); } > } this example indeed shows the problem. Let me explain to see if we agree on what the problem is. Suppose we don't artificially

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

Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.

Firstly, apologies if this is not the right place to be asking this question--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress()

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

Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs

Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does

On Apr 8, 2012, at 4:20 AM, Bill Wendling wrote: > On Apr 4, 2012, at 9:32 PM, Paul J. Lucas 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

Hi all, I'm compiling this trivial program on Darwin: 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

Hi! I am still working on the Win64 EH code and now have a pretty usable result. (The MC part is already posted to llvm-commits, the other part follows soon. If you are curious the whole patch is here: http://www.redstar.de/ldc/win64eh_all_20130524.diff.) However, in one case I have a problem with LLVM being too smart. Consider the following D code: void doIt() { printf("doIt:

I can't boostrap LLVM CFE at FreeBSD with current LLVM and LLVM CFE CVS sources. GCC bootstrap terminated with error: /usr/home/wanderer/pkg/build/llvm/objcfe/gcc/xgcc -B/usr/home/wanderer/pkg/build/llvm/objcfe/gcc/ -B/home/wanderer/pkg/build /llvm/night/cfe/i386-unknown-freebsd5.3/bin/ -B/home/wanderer/pkg/build/llvm/night/cfe/i386-unknown-freebsd5.3/lib/ -isystem