search for: dwarf_unwind

Hi, Can I interject something at this point. Can I suggest that invoke/unwind be renamed DWARF_invoke/DWARF_unwind to warn the unwary that if they want lightweight exception handling in their Python/ML/whatever implementation they should use some other method. PS. Kenneth, why don't you just use setjmp/longjmp directly. Or, if you want, I can email you my lightweight versions if you want, Mark. Duncan...

Hi, > How do either of these prevent DWARF exception handling from working? if you throw an exception using your proposed unwind implementation, then it wouldn't be caught by dwarf catch/cleanup regions (eg: invoke). > Would a landing pad expecting to get an exception object from the > exception intrinsics fail to get one in the case of an unwind and > crash? The landing pad

Hi Mark, > Can I suggest that invoke/unwind be renamed DWARF_invoke/DWARF_unwind to > warn the unwary that if they want lightweight exception handling in > their Python/ML/whatever implementation they should use some other method. probably there should be a switch to choose whether codegen should turn unwind/invoke into dwarf or setjmp/longjmp style code. Ciao, Dunca...

OK, I've read through http://www.llvm.org/docs/ExceptionHandling.html several times now. Let's see if I understand this... 1. Everywhere inside a "try" block, the C++ front-end emits "invoke" instructions instead of "call" instructions. Without any transformations, this "invoke" instruction compiles down to assembly code that doesn't seem to