similar to: [LLVMdev] Unwinds Gone Wild

Marc de Kruijf wrote: > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > definitely not inside the caller's unwind block My target is x86. > > As a simple test, I tried to compile the following code and I got a > segmentation fault. It looks good to me.

Hi, > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > really weird stuff -- unwinds are ending up in seemingly arbitrary places... > definitely not inside the caller's unwind block My target is x86. codegen doesn't know how to handle "unwind" on any target. You need to call the libgcc unwinding routines directly (or indirectly by

On Thu, Jul 31, 2008 at 2:19 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some > > really weird stuff -- unwinds are ending up in seemingly arbitrary > places... > > definitely not inside the caller's unwind block My target is x86. > > codegen doesn't know how to

> If you look at the generated x86 machine code, it looks like unwind is > compiled into nothing at all: Yes, unwind is currently not supported by the code generators. This is bad, but not that easy to fix (hopefully one day...). > I can't find any information about cxa_throw at all, not even a type > signature. If I could, could I just call it as if it were unwind, and it >

Duncan Sands wrote: >> I can't find any information about cxa_throw at all, not even a type >> signature. If I could, could I just call it as if it were unwind, and it >> would be caught by invoke? >> > > cxa_throw comes from the gcc C++ runtime. In order to see how to throw > and catch things correctly using it, compile some C++ examples down to >

On Mon, Sep 29, 2008 at 1:50 AM, Duncan Sands <baldrick at free.fr> wrote: > /* snip */ Just for another voice in here. 'unwind' and its kin would also be useful for me, especially since this is on platforms without GCC (nor is GCC used in any way in any step anywhere). Why does it generate GCC only constructs anyway, that does not sound very much like the multi-platform that

I guess Duncan's answer in this thread is the best answer to give: <<Once that [The exception handling stuff needed by llvm-gcc] was done I guess everyone took a breather and kind of forgot about unwind>> So yes, ultimately, unwind will be supported and clang/llvm should provide its own unwinding runtime. Patches welcome :) Cheers, Nicolas OvermindDL1 wrote: > On Mon, Sep

Duncan Sands wrote: > > since libgcc is available everywhere llvm is, it's as multi-platform > as llvm! If we didn't use libgcc then we'd have to introduce an llvm > runtime library. Since it would just duplicate the functionality of > libgcc, it would introduce an additional maintenance burden without > bringing any real advantage AFAICS. > So if there's

After much delay, I have finally reached the point in my work where I need to implement some kind of exception handling. I understand that "unwind" is currently unimplemented and will remain so for the forseeable future. In the mean time, are there any examples available for implementing Java or Python-style exceptions using __cxa_throw or something similar? I've read and

> So what about those of us who are implementing frontends that have no > connection with gcc or the c++ runtime at all? Are we out of luck as far > as unwind is concerned? For the moment, yes. If unwind gets implemented one day (I have a plan, but no time right now), the implementation is sure to call routines in the gcc runtime. Ciao, Duncan.

On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: > For the moment, yes. If unwind gets implemented one day (I have a plan, > but no time right now), the implementation is sure to call routines in > the gcc runtime. As a transient solution that makes sense, but it seems desirable to have a generalized unwind scheme that is not tied to libgcc. shap

Hi, > Why does it generate GCC only constructs anyway, that does not sound > very much like the multi-platform that LLVM is targeting. since libgcc is available everywhere llvm is, it's as multi-platform as llvm! If we didn't use libgcc then we'd have to introduce an llvm runtime library. Since it would just duplicate the functionality of libgcc, it would introduce an

Hi Talin, > 1) I'm trying to figure out the relationship between the __cxa_throw > function, and the _Unwind_RaiseException function mentioned in the ABI doc. > My guess is that _Unwind_RaiseException is the language-neutral > implementation of stack unwinding, and __cxa_throw is the C++ exception > semantics that are implemented on top of it. If that is the case, should I >

Hi Talin, Talin wrote: > After much delay, I have finally reached the point in my work where I > need to implement some kind of exception handling. I understand that > "unwind" is currently unimplemented and will remain so for the > forseeable future. > > In the mean time, are there any examples available for implementing Java > or Python-style exceptions using

Can you point out to me where in the VMKit code I should be looking? I spent some additional time reading the docs, and I have some specific questions: 1) I'm trying to figure out the relationship between the __cxa_throw function, and the _Unwind_RaiseException function mentioned in the ABI doc. My guess is that _Unwind_RaiseException is the language-neutral implementation of stack unwinding,

Jon Harrop wrote: > > Is it? I was just reading the documentation about LLVM's exception > handling > and it sounded ideal for my needs. How much of it does not work as the > docs > imply? > Jon, I ran into this issue in September and re-ignited this discussion in another thread, here: http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html

From what I understand, the unwind instruction is implemented only for the interpreter: there is a -lowerunwind pass for compiling to other systems which will either lower unwind and invoke to setjmp/ longjmp (slow) or turn invokes into calls and unwinds into abort()s. On 26 Dec 2008, at 15:19, Matt Giuca wrote: > > > Jon Harrop wrote: >> >> Is it? I was just reading

> In LLVM the rule is that an instruction must be dominated by its > operands. ... > We already have this issue with invoke. Consider: > > bb1: > %x = invoke i32 @f() to label %normal unwind label %unwind > normal: > phi i32 [%x, %bb1] > ret i32 %x > unwind: > phi i32 [%x, %bb1] ; illegal > ret i32 %x > > The PHI in %unwind must mention

On Sep 29, 2008, at 2:13 AM, Jonathan S. Shapiro wrote: > On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: >> For the moment, yes. If unwind gets implemented one day (I have a >> plan, >> but no time right now), the implementation is sure to call routines >> in >> the gcc runtime. > > As a transient solution that makes sense, but it seems desirable

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me