search for: setjump

...setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing setjump/longjump buffers). I'm moderately sure that SjLj presonality does not use system longjmp and does not claim to be binary compatible either. It usees the intrinsics. Joerg

...Recap: we use setjmp/longjmp for our exception handling on all platforms in our regular (non-LLVM) code generators. I'd like to use the same infrastructure with the LLVM code generator for code interoperability purposes (the LLVM SjLj personality is not binary-compatible with our existing setjump/longjump buffers). What I did was: 1) create a dummy personality function in our run time library that basically always says "no, this frame does not wish to handle this exception nor does it have any clean-up code", and specify it as personality function for any function that deals w...

...ction, 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 e...

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

...a0 +#define J_B0 0x1a8 +#define J_B1 0x1b0 +#define J_B2 0x1b8 +#define J_B3 0x1c0 +#define J_B4 0x1c8 +#define J_B5 0x1d0 +#define J_SIGMASK 0x1d8 +#define J_SIGSET 0x1e0 +#define J_GP 0x1f0 + +// int setjmp(struct jmp_buffer *) +// +// Setup a non-local goto. +// +// Description: +// +// SetJump stores the current register set in the area pointed to +// by "save". It returns zero. Subsequent calls to "LongJump" will +// restore the registers and return non-zero to the same location. +// +// On entry, r32 contains the pointer to the jmp_buffer +// + .align 32 + .glob...

...due to security concerns. Depending on your specific case, you may want to fall back to vectored exception handling. In my experience this was a dead end though. If you need a solution for arbitrary situations, you just can't jump back to a "safe" place to continue execution. I tried setjump (on each entry point to the dynamically loaded code) / longjmp (in the vectored exception handler), but the address was invalidated when I accessed it. I suspect it's kind of undefined behavior to call longjmp outside a child frame of the function that called setjmp. Anyway it turned all far to...

...y, 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 unwi...

...unction pointer and engine instance, retrieves the jitted C pointer, and calls it. - As this pointer is a pointer to fc, the unwind is then executed. Basically I have the call stack fa->fb->fc with fa, fc generated and fb not generated. Given that I was using the intuitive model of a setjump, longjump, I thought that fc's unwind would pass through fb and end up at fa's invoke's exception block. However it cores even though I've verified that each function is being executed. So I guess either there is something fundamental I don't understand, or I have anothe...

Hello friendly LLVM-World, because I don't know if I had send my problem to the correct Mailing-List, I will send my problem to this address too. I'm not subscribed to this list, so please add my in CC if you response. Kind regards Björn From: Bjoern Gaier/HE/HORIBA To: Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev" <cfe-dev-bounces at lists.llvm.org>

...to security concerns. Depending on your specific case, you may want to fall back to vectored exception handling. In my experience this was a dead end though. If you need a solution for arbitrary situations, you just can't jump back to a "safe" place to continue execution. I tried setjump (on each entry point to the dynamically loaded code) / longjmp (in the vectored exception handler), but the address was invalidated when I accessed it. I suspect it's kind of undefined behavior to call longjmp outside a child frame of the function that called setjmp. Anyway it turned all fa...

...specially with the Clang compiler. Out of curiosity I came along "Exception Handling in LLVM" and tried to understand the SJLJ exception handling. At first glance this made total sense to me! Store important registers and when the exception occurs - restore the saved registers. Kinda like setjump and longjump but with less registers. However, there are two things I really don't understand (about exception handling in general). I guess it works something like that: When I execute a function with a try-catch segment, as soon as I hit the try statement (Pretending I'm a Debugger or so...

.... > > Depending on your specific case, you may want to fall back to vectored > exception handling. In my experience this was a dead end though. If > you need a solution for arbitrary situations, you just can't jump back > to a "safe" place to continue execution. I tried setjump (on each > entry point to the dynamically loaded code) / longjmp (in the vectored > exception handler), but the address was invalidated when I accessed > it. I suspect it's kind of undefined behavior to call longjmp outside > a child frame of the function that called setjmp. Anyway...

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

...VM 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. > snip >> 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...

.... > > Depending on your specific case, you may want to fall back to vectored > exception handling. In my experience this was a dead end though. If you > need a solution for arbitrary situations, you just can't jump back to a > "safe" place to continue execution. I tried setjump (on each entry point to > the dynamically loaded code) / longjmp (in the vectored exception handler), > but the address was invalidated when I accessed it. I suspect it's kind of > undefined behavior to call longjmp outside a child frame of the function > that called setjmp. Anyway...

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not

I am trying to employ the ABCD optimization pass to remove unnecessary branches in the code my compiler generates. But in its current form (yesterday's trunk) the pass changes the behavior of the code such that execution yields invalid results, which is obviously not what I want. The switch in the following listing is used to implement a virtual method call, 99999 and 100000 are type

...Depending on your specific case, you may want to fall back to vectored >> exception handling. In my experience this was a dead end though. If you need >> a solution for arbitrary situations, you just can't jump back to a "safe" >> place to continue execution. I tried setjump (on each entry point to the >> dynamically loaded code) / longjmp (in the vectored exception handler), but >> the address was invalidated when I accessed it. I suspect it's kind of >> undefined behavior to call longjmp outside a child frame of the function >> that called...

...ectored >> >> exception handling. In my experience this was a dead end though. If you >> >> need >> >> a solution for arbitrary situations, you just can't jump back to a >> >> "safe" >> >> place to continue execution. I tried setjump (on each entry point to >> >> the >> >> dynamically loaded code) / longjmp (in the vectored exception handler), >> >> but >> >> the address was invalidated when I accessed it. I suspect it's kind of >> >> undefined behavior to call lon...

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: