search for: unwinders

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

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

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 bytecode

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

...> On Behalf Of Julian Lettner via llvm-dev > Sent: Monday, February 25, 2019 1:30 PM > To: llvm-dev at lists.llvm.org > Subject: [EXTERNAL] [llvm-dev] [Sanitizers] Platforms that don't support stack unwinding > > Hi, > > In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace. > > I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of...

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

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

> 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

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

...nteresting optimization potential, and without loss of semantic fidelity. Furthermore, I believe that LLVM IR should be able to reasonably express the full range of behavior of the platform's exceptions implementation. Specifically, we should able to implement resumptive exception handlers on unwinders that support them, which (to summarize briefly) is all of above. Now, obviously, actually implementing codegen lowering for resumptive handlers is not an immediate priority (although the problems there roughly coincide with the problems we'd face in implementing SEH); I'm just saying that...

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,