search for: unwound

Hi, Is it possible to add edges to the CFG from instructions that reference memory to exception landing pads? I want to do this so that I can convert SEGV signals into exceptions that can be safely unwound and caught. My compiler's existing code generator handles this by having a combined memory dereference and jump on null instruction. LLVM doesn't seem to have anything similar - I was thinking I might simulate this by adding a new instrinsic for potentially faulting memory references. Does...

...es not require a register file save/restore. The issue is in the non-throw case. Consider a function like this: int x = ... try { x++; foo(); use (x); } catch (...) { print x; } Because the 'throw' doesn't restore the callee-save registers as the stack is unwound, the compiler can't put X in a register across the x+ + and use of x in the try block. -Chris

Hi James, > Is it possible to add edges to the CFG from instructions that reference > memory to exception landing pads? I want to do this so that I can > convert SEGV signals into exceptions that can be safely unwound and > caught. My compiler's existing code generator handles this by having a > combined memory dereference and jump on null instruction. LLVM doesn't > seem to have anything similar - I was thinking I might simulate this by > adding a new instrinsic for potentially faulting...

...> > > 1. What happens when actual exception type isn't listed in catch or > > filter clauses? Does it still return the corresponding structure like if > > it was listed? Or behavior is undefined? > > if it doesn't match a clause then the exception continues to be unwound. > Note that you can match a catch clause without being equal to the type > in the catch clause (for example because the catch clause type represents > some class B, and thus will also match a class A if B derives from A). [snippet] It would be great if this can be put somewhere on the...

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving the same problem? What would be the best approach to catch exceptions from dynamically generated code on Win64?...

...oes not let > exceptions unwind through it (instead control branches to the landing pad). > So when inlining it into another function, there is no need to do anything > with it: it is not a throwing instruction. This logic assumes that inlining > does not affect whether an exception is unwound or not. It is true that *if* > an exception is unwound then the code produced by the LLVM inliner will > function correctly. But what if it is not unwound in the first place because > whoever is doing the unwinding looks up the call stack and bases its decision > as to whether to unwi...

On Nov 28, 2007, at 15:18, Chris Lattner wrote: > On Tue, 27 Nov 2007, Gordon Henriksen wrote: >> > >> The codegen for raise is simple. It just reads a saved return >> address from the caml_exception_pointer global and returns through >> several stack frames in one go. > > Nice. Yup. >> The try-with expression is where the trickery lies. The

Hi! I have a little problem using LLVM and will be happy to get a solution. I need to handle in C++ code an uncaught unwind instruction while calling JIT (now I get segfault). I mean something like nonexistent ExecutionEngine::invokeFunction instead of callFunction. Setting llvm::JITExceptionHandling to true and enclosing the JIT-call within try/catch block does not help here, because there is no

...ome > questions open: > > 1. What happens when actual exception type isn't listed in catch or > filter clauses? Does it still return the corresponding structure like if > it was listed? Or behavior is undefined? if it doesn't match a clause then the exception continues to be unwound. Note that you can match a catch clause without being equal to the type in the catch clause (for example because the catch clause type represents some class B, and thus will also match a class A if B derives from A). > 2. What is 'somety'? Shouldn't it maybe say "result_type&qu...

I am new to the landingpad (which is relatively new too). Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some questions open: 1. What happens when actual exception type isn't listed in catch or filter clauses? Does it still return the corresponding structure like if it was listed? Or behavior is undefined? 2. What is 'somety'? Shouldn't it maybe say

...tes noreturn, nounwind, willreturn mean. The most explicit way would be listing all the possible outcomes of calling a function and exclude possibilities per attribute. 1. Call returns to next instruction / invoke branches to "to" block. 2a. Call throws synchronous exception and stack is unwound to parent caller 2b. Invoke throws synchronous exception and branches to "unwind to" block 3a. Call throws asynchronous exception and stack is unwound to parent caller 3b. Invoke throws asynchronous exception and branches to "unwind to" block 4a. Call/invoke triggers thread/prog...

...ing about this also...?... It would be difficult to reliably reconstruct try/catch statements from the IR even before optimization. > 4) IIUC, llvm has inherited a bug from gcc where the debugger cannot let the user know an exception is > going to be uncaught until after the stack has been unwound -- contrary to the design intentions of the > unwind library that most exception implementations are based on (with a two phase unwind algorithm) -- > which creates a problem for the debugger user. I don't see this as a compiler bug. I can't imagine any personality function design...

...counter-- spin_unlock() So now the oom path does: invalidate_range_start_non_blocking: for each mn: a->invalidate_range_start b->invalidate_range_start rc = EAGAIN Now we SKIP A's invalidate_range_end even though A had no idea this would happen has state that needs to be unwound. A is broken. B survived just fine. A and B *alone* work fine, combined they fail. When the commit was landed you can use KVM as an example of A and RDMA ODP as an example of B Jason

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 Jul 27, 2011, at 11:10 AM, John McCall wrote: > >> 4) IIUC, llvm has inherited a bug from gcc where the debugger >> cannot let the user know an exception is >> going to be uncaught until after the stack has been unwound -- >> contrary to the design intentions of the >> unwind library that most exception implementations are based on >> (with a two phase unwind algorithm) -- >> which creates a problem for the debugger user. > > I don't see this as a compiler bug. I can't im...

...tack up to invoke call? Is there an alternative to establish a custom exception handling? 2011/11/7 Duncan Sands <baldrick at free.fr> > >> Hi Semion, the unwind instruction has been removed from LLVM. Also, the >> JIT >> and code generators never supported it: it never unwound the stack, it >> just >> resulted in a nasty crash. >> >> Ciao, Duncan. >> >> > I have a little problem using LLVM and will be happy to get a solution. >> I need >> > to handle in C++ code an uncaught unwind instruction while calling JIT >&gt...

...ever run into. very true. That said, it is a pity not to support other ways of doing exception handling. For example, you could declare every function to return two results, the usual one and an additional i1 result. If the i1 value returned is 1 then this means that "an exception is being unwound", and the caller should jump to the landing pad if there is one; and if there isn't then it itself should return 1. This scheme doesn't write memory. OK, now imagine implementing this scheme where the additional return value is hidden, only implicitly present. You can argue that the...

...gt;> recent versions of GCC do. >>> >> I'm not a big fan of implicit behavior. :) > > It would be explicitly documented, so then it wouldn't be implicit! In fact > it would mean that "invoke" has the traditional LLVM semantics: if an exception > is unwound then control branches to the landing pad. With the new scheme that > is currently no longer so - meaning that some of the PruneEH logic is currently > wrong :) That said, I'm also a bit dubious about this "always has a cleanup" > idea. > The traditional LLVM semantics o...

...rsonality and tells it that there is a handler above it? Nope. > The traditional LLVM semantics of exception handling were broken. I don't want to go back to them. :-) They weren't really broken, it was the inliner that was using them wrong. The subtlety is that *if* an exception is unwound (by this I mean *phase 2*, i.e. the actual running of handlers and cleanups) *then* indeed it was true that control branched to the landing pad. But what was forgotten is that whoever is doing the unwinding might make its decision as to whether to unwind or not (i.e. perform phase 2) based on what...

...lock); > + > + vdpa = &vdpasim->vdpa; > + vdpa->dev.release = vdpasim_release_dev; The driver should not provide the release function. Again the safest model is 'vdpa_alloc_device' which combines the kzalloc and the vdpa_init_device() and returns something that is error unwound with put_device() The subsystem owns the release and does the kfree and other cleanup like releasing the IDA. > + vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu); > + vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu); > + > + dev = &vdpa->dev...