similar to: [LLVMdev] Unwinds Gone Wild

On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes? Don't mix VC runtime and libgcc. These are totally different libraries for doing

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

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

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

Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not

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

> 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 >

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

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

> probably there should be a switch to choose whether codegen should turn > unwind/invoke into dwarf or setjmp/longjmp style code. There is, but it happens before codegen and is slow. -enable-correct-eh-support will translate invoke/unwind into setjmp/longjmp pairs for the correct behavior. See: http://llvm.org/docs/Passes.html#lowerinvoke Nick > > Ciao, > > Duncan. >

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 >

> 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

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

Nick Johnson wrote: >> probably there should be a switch to choose whether codegen should turn >> unwind/invoke into dwarf or setjmp/longjmp style code. It seems to me that there is an implicit, and undocumented, assumption that unwinding needs to handle stack-allocated objects. In languages without stack-allocated objects (ie. most languages that support exceptions) there is no

Kenneth Uildriks wrote: > 3. Perhaps a pass that lowers unwinds to an EH intrinsic? Would that > map well without adding more overhead than the current setjmp/longjmp > lowering pass? In the past there have been suggestions that a good approach would be to target the libunwind (http://www.nongnu.org/libunwind/) library interface in a lowering pass. This could provide both low

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.

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

On Wed, 20 Apr 2005, Greg Pettyjohn wrote: > I'm trying to get unwind to work. > > I was unable to get an unwind example to work directly, > so I decided to compile a c program that uses setjmp > and longjmp and work backwards. > > I keep running into a "Abort trap" problem, whatever "Abort trap" is. > > Anyway, here's an example of a C

I'm trying to get unwind to work. I was unable to get an unwind example to work directly, so I decided to compile a c program that uses setjmp and longjmp and work backwards. I keep running into a "Abort trap" problem, whatever "Abort trap" is. Anyway, here's an example of a C program that compiles and works properly under normal gcc, but that fails with an