The documentation of unwind/invoke is quite clear and does exactly what I need: unwinding the stack. I don't need it to carry an object back. I don't need it to figure out what the type of the object is or what catch() blocks it matches. I just need it to unwind the stack. The rest is my job as a part of the runtime. Unfortunately, I have learned that while this works with the bytecode evaluator, it doesn't work with the JIT or native codegen [1]. There seems to have been discussion about making unwind/invoke inter-operate with native c++ exceptions, and this complexity was cited as being the reason it was too complex to implement. I question whether this is actually needed. In other languages, I >do not< want C++ exceptions to try and unwind my stack, nor do I want my exceptions to unwind a C++ stack. The exceptions are completely incompatible and this would not make sense. To implement exceptions in a new frontend, unwind functionality is required. LLVM generates all the stack frame information, so a front-end author is not in the position to unwind the stack himself. When I read the LLVM documentation I thought it could do this, and I was extremely disappointed to learn that it could not. This missing functionality means (as far as I can tell) that I will not be able to implement a backend for ML which uses LLVM directly. Instead I would need to use a trampoline to effectively remove LLVM from stack control and manage a stack in the heap explicitly. This seems quite a shame since LLVM was clearly intended to function as a SSA backend. I would ask that the documentation for unwind be updated to reflect that this operation does not actually exist. Such a warning would have saved me two weeks of wasted implementation effort. [1] http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html
> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned that while this works with the bytecode evaluator, it doesn't > work with the JIT or native codegen [1].DWARF EH maybe what you want, it has zero overhead on normal calls and I believe it is built into LLVM's assemblers. A DWARF style EH is also built into the JIT too. Aaron
On Mon, Jun 15, 2009 at 7:08 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote:>> The documentation of unwind/invoke is quite clear and does exactly >> what I need: unwinding the stack. I don't need it to carry an object >> back. I don't need it to figure out what the type of the object is or >> what catch() blocks it matches. I just need it to unwind the stack. >> The rest is my job as a part of the runtime. Unfortunately, I have >> learned that while this works with the bytecode evaluator, it doesn't >> work with the JIT or native codegen [1]. > > DWARF EH maybe what you want, it has zero overhead on normal calls and I > believe it is built into LLVM's assemblers. A DWARF style EH is also built > into the JIT too.How do I tell llc to output dwarf-style 'unwnd' ? Both -enable-eh and -enable-correct-eh-support compile 'unwind' to nothing on x86 with llc v2.5.
Hi Wesley,> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned that while this works with the bytecode evaluator, it doesn't > work with the JIT or native codegen [1].you can call the libgcc/libunwind routines directly. There was an example of this on the mailing list by Talin not long ago. That said, it wouldn't be too hard to support "unwind" in the code generators. It would basically mean creating thread-local storage to hold dwarf exception information, and turning "unwind" into some code to set up the info and call the appropriate libgcc routine. Unfortunately no-one was interested enough to do it yet. Ciao, Duncan.
On Mon, Jun 15, 2009 at 9:40 PM, Duncan Sands<baldrick at free.fr> wrote:> you can call the libgcc/libunwind routines directly. There was an > example of this on the mailing list by Talin not long ago.I'll look into this. Thanks.> That said, > it wouldn't be too hard to support "unwind" in the code generators. > It would basically mean creating thread-local storage to hold dwarf > exception information, and turning "unwind" into some code to set up > the info and call the appropriate libgcc routine.Why does 'unwind' need to setup thread local storage at all? In my opinion this is the responsibility of the frontend, not LLVM. All I expect 'unwind' to do is unwind the stack down to the nearest 'unwind label' of an invoke. Thread-local storage, global variable, or any other approach one might think of to carry the exception information is a frontend policy decision. Adding this support to 'unwind' complicates its implementation and also dilutes its usefulness.
* Wesley W. Terpstra:> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack.You can use your stack switching mechanism for this purpose.
Florian Weimer wrote:> * Wesley W. Terpstra: > >> The documentation of unwind/invoke is quite clear and does exactly >> what I need: unwinding the stack. I don't need it to carry an object >> back. I don't need it to figure out what the type of the object is or >> what catch() blocks it matches. I just need it to unwind the stack. > > You can use your stack switching mechanism for this purpose.Or call libunwind directly. Ciao, Duncan.