search for: unwinds

...hich will not save the link register if the callee function has noreturn attribute [1]. Even though the optimization will only be applied when the callee function has nounwind attribute as well, the problem still occurs because PruneEH will (incorrectly) add nounwind to some function which actually unwinds. Besides, I am in doubt about whether we can apply this optimization when the caller function has the uwtable attribute and requires the unwind table. # Unwind Table and Can't Unwind The mixture of uwtable and nounwind will cause another problem. IMO, it is incorrect to decide whether to emi...

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

Hi Bill, >> The unwinder delegates the decision of whether to stop in a call frame to >> that call frame's language-specific personality function. Not all personality >> functions guarantee that they will stop to perform cleanups. I was talking about who decides what to do if there are only cleanups all the way up the stack (in C++ the program is terminated without

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

Hi Mark, > You are confusing stopping the unwinding at *some* levels or at *all* > levels. > Eg. > invoke > call > call > invoke > call > call > unwind the dwarf unwinder only stops and runs user code at the invokes. It does restore registers and so forth at every stack frame. This is extra work done at unwind time that reduces the cost

...eems quite a shame since LLVM was clearly intended to function as a SSA backend. I would ask that the documentation for unwind be updated to reflect that this operation does not actually exist. Such a warning would have saved me two weeks of wasted implementation effort. [1] http://www.nabble.com/Unwinds-Gone-Wild-td18747589.html

On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > * There's the table for ARM target: > > - no attribute => emit unwind table > - with nounwind => emit unwind table with cantunwind > - with uwtable => emit unwind table > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind > > The cantunwind record will stop the

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

On Sep 27, 2011, at 4:58 AM, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :) >

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

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. Can someone help me out or is this a bug? define i32 @foo() { entry:...

...-enable-correct-eh-support will translate invoke/unwind into > setjmp/longjmp pairs for the correct behavior. See: > http://llvm.org/docs/Passes.html#lowerinvoke *Begin rant* It is possible to implement invoke/unwind in such a way that both invoke *and* unwind are fast, when unwind just unwinds and doesn't perform any magic behind-the-scenes operations. After all, isn't it the job of the front-end to insert all the clean-up code for stack-allocated objects? Java, C#, Python, and Ruby have destructors(finalizers), but they are managed by the garbage collector. C++ is the odd o...

...om different compilation units). It doesn't have anything to do with stack-allocated vs heap-allocated, but rather with the language's guarantees about exceptions. > It is possible to implement invoke/unwind in such a way that both invoke >  *and* unwind are fast, when  unwind just unwinds and doesn't perform > any magic behind-the-scenes operations. > Why? Exceptions are supposed to occur in exceptional situations. In general, one should try to optimize for the common case, which does not include invoke/unwind. One should certainly not slow down a function call which n...

On Mon, Jun 15, 2009 at 9:40 PM, Duncan Sands<baldrick at free.fr> wrote: > you can call the libgcc/libunwind routines directly.  There was an > example of this on the mailing list by Talin not long ago. I'll look into this. Thanks. > That said, > it wouldn't be too hard to support "unwind" in the code generators. > It would basically mean creating

...n 2008-03-29, at 00:57, Nick Lewycky wrote: > >> Gordon Henriksen wrote: >> >>> What blocks would a phi node in %catch require for a case like this? >>> >>> define i8 @f(i1 %b) { >>> entry: >>> b label %try >>> try: unwinds to %catch >>> b i1 %b, label %then, label %else >>> then: unwinds to %catch >>> ret void >>> else: unwinds to %catch >>> ret void >>> catch: ; What are my predecessors? >>> ret void >>> } >&g...

Hi, I want to support the unwind instruction on x86. Specifically I want to: * Provide an efficient runtime implementation that does not depend on reading the DWARF EH information. * It should be self hosted, meaning the runtime is static linked in. I want to use it kernel mode. * Unwinding should be a read-only operation regarding the stack, so I can create a stack dump in the

Hi Mark, > So who is responsible for (as stated under the invoke description in the > language reference) "ensure that proper cleanup is performed in the case > of either a longjmp or a thrown exception"? the unwinder (however it works) needs to stop at each invoke and run the code in the unwind block of the invoke. I think it is important that the default method of code

...op precluding the possibility. These requirements punt on three major questions that I consider separable: - the structure or appearance of the actual IR: I'm just trying to lay down what I expect of the information preserved there; - what IR constructs can serve as origin points of unwinds: that is, whether exceptions can originate from: - only calls (status quo) - any instruction marked as potentially throwing (to support synchronous throwing signal handlers: e.g., null pointer exceptions and zero divides) - any arbitrary location (to support as...

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,