similar to: [LLVMdev] invoke and unwind

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

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

On Aug 13, 2011, at 4:44 PM, Carter Cheng wrote: > Hello, > > I was looking over the documentation support for exceptions and it indicates that the invoke unwind support is incomplete. Is this still the case in 2.9? > Hi Carter, The use of the term "unwind" is a bit confusing in this context. The "invoke" instruction has an "unwind" clause, which is

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

Hello, I was looking over the documentation support for exceptions and it indicates that the invoke unwind support is incomplete. Is this still the case in 2.9? Regards, Carter. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110814/400bcca0/attachment.html>

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

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

> 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

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 >

* 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

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

What is the difference between a CallInst and an InvokeInst in LLVM? Is an InvokeInst a CallInst that can throw an exception? Thanks, Ryan

Here is a small doc patch based on answers from the list and from the links mentioned. For stylistic consistency I've followed the language in the va_arg description for the analogous situation. Dustin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LangRef.unwind.patch URL:

I don't mean to be a pain, but I was thinking about this a bit more. Does gcc ignore the const keyword? If not, why has LLVM chosen to deviate from gcc with respect to the const keyword? If so, then why do we bother using const in LLVM API code? I'm just curious and wanted to understand the thinking behind not preserving const. Thanks, Ryan Chris Lattner wrote: > This property

Hi Dustin, > Here is a small doc patch based on answers from the list and from the > links mentioned. For stylistic consistency I've followed the language > in the va_arg description for the analogous situation. as I mentioned in another email, unwind is not completely unsupported: it does work for rethrowing an exception. Ciao, Duncan.

I don't follow what you mean - gcc doesn't ignore const and llvm doesn't deviate from gcc nor from the relevant language standards. Note that if you declare a global as const that we do capture this in the ir - what specifically do you want? Please provide an example. -Chris http://nondot.org/sabre http://llvm.org On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"

Hi Dustin, the code generators do not support unwind, only the interpreter does. Ciao, Duncan.

I have a new plan for handling 'unwinds to' in the control flow graph and dominance. Just as a quick recap the problem I encountered is how to deal instructions in a block being used as operands in the unwind dest. Such as this: bb1: unwinds to %cleanup call void @foo() ; might throw, might not %x = add i32 %y, %z call void @foo() ; might throw, might not ret void cleanup:

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.cpp It does, although in the "let me show you why this is too much to tackle" way. > Although this is a pure example that