search for: unwind

Hi all, I feel that there are two problems with the existing infrastructure: * The nounwind attribute is ambiguous for (1) not throwing exceptions and (2) not performing stack unwinding. I feel that it will be better to separate this in two different attributes * There is some problem when the function has both uwtable and nounwind. Although, I think it fine to keep the current definitio...

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 could even print the function names with jus...

...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> wrote: > Hi Evgeniy, > > I have run in to the some unwind handling table issue recently. After some > investigation, I believe that the correct behavior is to generate > [cantunwind] with and without the -funwind-tables. Thus, I am afraid that > -funwind-tables might not be a good solution for your use case. (i.e. your > program might fall...

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

...t 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 exceptional logic which I think we should give it a try. I'm trying to make it as backward compatible as possible, but the point is to make the IR authoritative on how and when to emit what kind of unwind information. ** Unwinding ** AFAIK, there are three ways to unwind the stack: 1...

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

The documentation of unwind/invoke is quite clear and does exactly what I need: unwinding the stack. I don't need it to carry an object back. I don't need it to figure out what the type of the object is or what catch() blocks it matches. I just need it to unwind the stack. The rest is my job as a part of the runtime....

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 unwinder, and cantunwind will conflict > with the stack unwind...

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 meant: Shouldn’t there be at...

...;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. :) > > I still have some niggles: > > 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. > > This is incorrect: it is not the personality function that makes the d...

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

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

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 need to unwind fra...

> In languages without stack-allocated objects (ie. most languages that > support exceptions) there is no need to unwind frame-by-frame, the > unwind simply needs to make a single jump to the invoke instruction and > restore the context (which in x86 is just 6 registers). > No. Java, C#, Ruby and Python all support the finally/ensure block; C# supports the using( IDisposable x =...) {} construct. Both con...

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 thread-local storage to ho...

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

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

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 generation for the unwind and invoke instructions should interact correctly with code compiled with gcc. This means that the default needs t...

...'re going to start discussing changing the EH representation again, I think it would be a very good idea to first review the core requirements we have of the exceptions IR. Mostly, here, I'm taking the major exceptions implementations I have direct knowledge of --- zero-cost DWARF-based libUnwind with the default GCC personalities, builtin_sjlj-based libUnwind with the same personalities, various alternative personality proposals I've been asked to consider, and C++ over SEH --- and trying to make sure that LLVM IR can reasonably express them with high quality, with interesting optimiza...

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, and __cxa_throw is the C++ exception semantics that are implemented on top of it. If that is the case, should I be calling _Unwind_RaiseException sinc...