similar to: [LLVMdev] About unwind...

Hi Sebastien. On Dec 15, 2007, at 19:00, Sebastien Loisel <loisel at temple.edu> wrote: > I have started playing with LLVM a little bit and I am thinking of > using it to write some linear algebra software for my class. > > I was reading the documentation and I am very excited by the > possibilities of "invoke" and "unwind". I have two questions. >

> 2) When I unwind, the stack gets popped but it would make sense to pass some > data to the exception handler. I guess I could use a global variable for > this, but is there a way to do it on the stack? (Wouldn't that make more > sense also?) Passing extra info on the stack doesn't make much sense because the stack gets popped... Also, note that the unwind instruction is

OK, I have learnt something about llvm from this thread, thanks. As a side note: > 2) When I unwind, the stack gets popped but it would make sense to pass > some > Passing extra info on the stack doesn't make much sense because the stack > gets popped... > I don't know how llvm implements unwind, but in principle it is possible to walk (and pop) the stack to the right

Hi Kenneth, this way of implementing unwind won't interact properly with dwarf exception handling. That's rather bad. Ciao, Duncan.

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

According to this page: http://lwn.net/Articles/252125/ data coming from L1 is only about three times as expensive as data coming from a register. So putting a register check after *every* call is probably not going to be profitable, compared to a thread-local global variable check after every invoke... if they happen often on a thread, that variable will probably be in cache, and if they

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

I'm catching up on this. Does this mean LLVM x64 JITTed code is not exception friendly or you can't catch exceptions inside LLVM JITTed code. The first one seems to indicate that the code is not ABI friendly or that not enough information is present to notify Windows of unwind tables. I'll ask the question another way: Does LLVM emit enough information so that RtlAddFunctionTable can

OK, I've read through http://www.llvm.org/docs/ExceptionHandling.html several times now. Let's see if I understand this... 1. Everywhere inside a "try" block, the C++ front-end emits "invoke" instructions instead of "call" instructions. Without any transformations, this "invoke" instruction compiles down to assembly code that doesn't seem to

Hi Bjoern, I'm trying to make exceptions run. I have an Object file with a function, > throwing a 1 and a second function which should catch the 1. Normal JITTING > under Windows showed me, that I have an unresolved reference to the virtual > table of type_info. Some experiments later I was able to load "msvcrt.lib" > as an archive and could resolve the reference. Nice -

Function.cpp:167: error: call of overloaded `AddInteger(uint32_t&)' is ambiguous /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:151: note: candidates are: void llv m::FoldingSetImpl::NodeID::AddInteger(int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:152: note: void llvm::FoldingSetIm pl::NodeID::AddInteger(unsigned int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:153: note: void

That's encouraging. Assuming that all access to the JITted code is going to be done through a function pointer, and all JIT code is ephemeral, why is the object container format important? In fact, why is it even needed? I found it somewhat odd that MCJIT generates an object file for even the JIT case. To answer my own question, could it be that advanced JIT's may need/want to use things

Hello everyone, I was wondering what is the status regarding exceptions for the windows-msvc target? The corresponding part of the documentation (llvm/decs/ExceptionHandling.rst) hasn't been updated since 2015, was there any progress since? This is most likely known, but there's significant divergence between the behavior of MSVC cl.exe and clang-cl.exe: Consider: void crash() {

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hi Jb, It's good to see someone step up and take a shot as this again. I dropped this because it seems to me it wasn't a high priority task for LLVM/Clang. Implementing SEH is more of LLVM work than Clang work. For 32-bit SEH, there are prologue/epilogue instruction sequence to emit, setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all these can only happen in LLVM, not

https://llvm.org/docs/ExceptionHandling.html#wineh > No variables live in to or out of the funclet can be allocated in registers. I don't think this is quite true. though it might be a useful simplification. Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

Hello, I'm in the process of creating a JIT and I've run into a problem with exception handling. The situation I'm in is that my program will JIT functions, which will call native C++ functions (part of the run-time support). These native functions can throw exceptions. However, I don't actually want to handle these exceptions in the JITted functions. There are already try/catch

I'm trying to add some basic exception handling to my language now and I'm uncertain of how I actually start the exception propagation. It appears that "resume" will continue the exception, but I see no mention of how the exception actually starts. If I look at the IR output of a simple C++ program I see that it calls @__cxa_throw, but that is a library function. Somehow I must

Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function