search for: dwarfexceptionhandl

...--help says: "-enable-eh - Emit DWARF exception handling (default if target supports)" But in fact the default on x86-64 linux seems to be disabled, even though exception handling is supported both for lli and when I use the JIT as a library. Is this a bug? I can't find where llvm::DwarfExceptionHandling is being conditionally set by the JIT based on exception handling support. -- James Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100304/ba1ce122/attachment.html>

...able-eh - Emit DWARF exception handling (default if target supports)" > > But in fact the default on x86-64 linux seems to be disabled, even > though exception handling is supported both for lli and when I use the > JIT as a library. Is this a bug? I can't find where > llvm::DwarfExceptionHandling is being conditionally set by the JIT based > on exception handling support. I'm not sure what you are asking. Are you saying that eh doesn't work with the JIT on x86-64? Or are you saying that it does work, and wondering why because this option seems to be off? Ciao, Duncan.

...rsonality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed could affect this), _Unwind_RaiseException(...) is not being called, or the default or another personality function (_gcc_personality_v0(...)) is called instead by the unwind infrastructure. Although you implied you dumped the exception headers and found your personality...

...ed at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either dwarf exception header info is not > emitted (llvm::DwarfExceptionHandling = true; > not executed could affect this), _Unwind_RaiseException(...) is not being > called, or the default or another personality > function (_gcc_personality_v0(...)) is called instead by the > unwind infrastructure. Although you implied you > dumped the exception headers and...

2010/1/22 Duncan Sands <baldrick at free.fr> > 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

...ed at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either dwarf exception header info is not > emitted (llvm::DwarfExceptionHandling = true; > not executed could affect this), _Unwind_RaiseException(...) is not being > called, or the default or another personality > function (_gcc_personality_v0(...)) is called instead by the > unwind infrastructure. Although you implied you > dumped the exception headers and...

...too. Are there any other intrinsics that changed? 4. SetCurrentDebugLocation takes a DebugLoc now 5. VISIBILITY_HIDDEN is gone 6. SMDiagnostic takes different parameters 7. APIs renamed: llvm_report_error -> report_fatal_error llvm_install_error_handler -> install_fatal_error_handler llvm::DwarfExceptionHandling -> llvm::JITExceptionHandling 8. disable calls to memory_barrier. this is not correct for SMP but at least its not crashing. I'll probably have more to add to this list once I try to port our bytecode compiler. > Leading up to that date, > please make sure that the tree is stable...

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

Good news, everybody! It's that time of year again. We are going to release LLVM 2.8! I'm taking over for Tanya to give her a much needed break. I can only hope to perform as well as she has. This is my first time as release manager, so bear with me if things don't go smoothly. This message is mostly to give you an idea of the schedule we're planning on. It's an aggressive

Hi, I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. If you are a "sophisticated" JIT user and are using either internal APIs (either by integrating with LLVM, or by other C++ tricks), or are using obscure or poorly documented public APIs (e.g., why is runJITOnFunction exposed?) please make me aware of it! I reserve the right to break anything which