I put invoke/unwind aside because I couldn't get them to work, but I'm working on my evaluator now and it would be nice to figure this out so I don't have to unwind the stack manually. This was the reason for my earlier question about global declarations, and as that's cleared up I can easily pass exception data...if I can make unwind return out of some deep recursion. The behavior I get is sort of odd and took a while to characterize--unwind returns every time if done one level deep in the same translation unit. If I try it across translation units, or more than one call deep, I get a seg fault every time. I have reduced the problem to a trivial test case which I can post if there is an obvious "you idiot, everyone knows you have to frob your gismoids" answer. Dustin
Hi Dustin, the code generators do not support unwind, only the interpreter does. Ciao, Duncan.
If it helps, to see what is involved, outside of a pure IR context, see the example code, and doc at: http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cpp Although this is a pure example that shows several test cases, including foreign exception interaction, it is not an IR example, but rather a LLVM IR API example. It would be interesting to see a pure IR version of a personality function. I don't see why this would not be possible, although costly in terms of effort. Clang would help. There are also ways to lower your invoke/unwind into a setjump/longjump implementation, but I do not know how to do this in IR, as it requires function pass setup which is outside the scope of IR. Garrison On Jan 13, 2010, at 4:40, Dustin Laurence wrote:> I put invoke/unwind aside because I couldn't get them to work, but I'm > working on my evaluator now and it would be nice to figure this out so I > don't have to unwind the stack manually. This was the reason for my > earlier question about global declarations, and as that's cleared up I > can easily pass exception data...if I can make unwind return out of some > deep recursion. > > The behavior I get is sort of odd and took a while to > characterize--unwind returns every time if done one level deep in the > same translation unit. If I try it across translation units, or more > than one call deep, I get a seg fault every time. > > I have reduced the problem to a trivial test case which I can post if > there is an obvious "you idiot, everyone knows you have to frob your > gismoids" answer. > > Dustin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, Jan 13, 2010 at 4:07 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Dustin, the code generators do not support unwind, only the > interpreter does. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >I thought someone implemented invoke/unwind for x86 a few months ago. I remember seeing a post to that effect.
On 01/13/2010 02:07 AM, Duncan Sands wrote:> Hi Dustin, the code generators do not support unwind, only the > interpreter does.Ah, the secret is not to even try to frob the gnorts. Manual unwinding, here I come. :-( I was going to say the interpreter doesn't either, but then I recalled it JITs when it can. I don't know how to call into libc from the interpreter to test that. So how is clang doing C++ exceptions? Dustin
On 01/13/2010 04:08 AM, Garrison Venn wrote:> If it helps, to see what is involved, outside of a pure IR context, > see the example code, and doc at: > > http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cppIt does, although in the "let me show you why this is too much to tackle" way.> Although this is a pure example that shows several test cases, > including foreign exception interaction, it is not an IR example, but > rather a LLVM IR API example. It would be interesting to see a pure > IR version of a personality function. I don't see why this would not > be possible, although costly in terms of effort. Clang would help.Beyond the scope of the project, I guess. Sounds too far out on the diminishing returns curve for knowledge. If I spend too much time handcoding IR the first extension to the project would be to write a "high-level IR" front-end that provides a 1-1 mapping of the semantics, but with handcoding-friendly syntax and tools. It would actually save time at some level, given that I'm manually #including headers just to reduce the amount of code duplication to saying it twice instead of many times. Complete aside--I hate when people tell me something is impossible, even me. :-) So after I said you couldn't do without CPP-style #includes a few days ago I was annoyed enough to design in my head an import/export mechanism using only unix tools everyone has laying around. Just to prove myself wrong, I guess. I'm not sure I'll implement it given that I already have a lot of code written the other way, but LLVM syntax is simple enough that it could be done without parsing the IR. I don't know if I have enough IR left to justify switching over, but it would be satisfying in principle to get rid of the duplication of headers.> There are also ways to lower your invoke/unwind into a > setjump/longjump implementation, but I do not know how to do this in > IR, as it requires function pass setup which is outside the scope of > IR.I don't know enough about how setjmp/longjmp are implemented to have a clue. If I'm getting into uncharted territory it's easier to just unwind the evaluator stack by hand, just as I already did with the parser when unwinding didn't work. The focus is on learning IR and about the simple lisp evaluation model. There are actually limits to my madness, you know. :-) It would be more profitable to learn another aspect of the system by implementing a MMIX back-end or something. Or, and I know this is just *crazy* talk, I could actually follow the intended learning path and use the main C++ API for something. :-) Dustin