search for: unwinding

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 definition of nounwind, however, the uwtable attribute will be much useless to its user. Besides, even...

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

...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 in an infinite loop during stack unwinding.) > > I will send the details for discussion ASAP. > > Sincerely, > Logan > > > On Thu, Feb 13, 2014 at 10:03 PM, Evgeniy Stepanov <eugenis at google.com> > wrote: >> >> On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org> &gt...

...is a real handler somewhere; the throw routine decides what to do based on what the unwinder tells it). As far as I know all personality functions treat cleanups the same. >> This is incorrect: it is not the personality function that makes the decision, >> it is who-ever is doing the unwinding. For example if you use the Ada "throw" >> method it will always run all C++ cleanups, even if that's all there is to do. >> While if you use the C++ throw method it won't bother running Ada cleanups if >> that is all there is to do. All personality functions t...

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

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

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. Unfortunately, I have learned that while this works with the b...

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

...le for a given binary to have zero unwind information. The easiest example is a 32-bit x86 Windows binary (and maybe Linux?) built with frame-pointer-omission. There are no unwind tables in that situation, and you can’t just follow frame pointers backwards, because they don’t exist. This kind of unwinding generally requires debug information. Maybe, in some specific cases, you could analyze the assembly to figure out how to unwind it, but in the general case, that requires solving the halting problem. > > Embedded platforms often omit all unwinding information to save space. > > If...

...op 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 decision, > it is who-ever is doing the unwinding. For example if you use the Ada "throw" > method it will always run all C++ cleanups, even if that's all there is to do. > While if you use the C++ throw method it won't bother running Ada cleanups if > that is all there is to do. All personality functions that I am fam...

> 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() {

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

> 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

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

Gordon Henriksen wrote: > On 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

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 landing pad. * Provide a pass that raises C++ exception handling to just unwind instructions and thread-local data. My idea on handling the DWARF EH actions is to compile it to machine instructions....

...) 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 to make use of dwarf unwinding. It does not prevent having multiple code generation implementations, eg done using some kind of setjmp/longjmp implementation of unwind/invoke. Code created using other implementations will only work correctly if the entire executable, or at least the bits doing exception handling, are all built...

...cost-dwarf unwinder family, and as long as that personality uses an LSDA that looks like the zerocost DWARF LSDA, everything should be fine. Unwinders generally operate in units of call frames. When considering a call frame, an unwinder must have a complete idea of the frame's desired unwinding behavior. It is not burdensome for a frontend to make sure it generates a complete picture of the local context within a function, but IPO inherently complicates this. It is not desireable for IPO to be inhibited by the mere presence of exception code or for IPO to break semantics. Given suffici...

...al 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 since my exceptions are more like Java than C++ exceptions? 2) How portable is _Unwind_RaiseException and similar functions? In particular, if I call t...