search for: _unwind_resume

On Sep 17, 2009, at 6:03 PM, Duncan Sands wrote: > Hi Bill, > >>>> Yeah. The logic will need tweaking for sure. I'm also concerned >>>> about the >>>> _Unwind_resume() call. GCC emits a call site region for it in the >>>> exception >>>> table. We...kind of do that. It looks like it's being included in >>>> one of the >>>> "this is a region which isn't in a try-catch block, but it has a >>&...

On Thu, Sep 17, 2009 at 3:40 AM, Duncan Sands <duncan.sands at math.u-psud.fr> wrote: > Hi Bill, > >> Yeah. The logic will need tweaking for sure. I'm also concerned about the >> _Unwind_resume() call. GCC emits a call site region for it in the exception >> table. We...kind of do that. It looks like it's being included in one of the >> "this is a region which isn't in a try-catch block, but it has a call in it, >> so lets add it to the exception table"...

Hi Bill, >>> Yeah. The logic will need tweaking for sure. I'm also concerned about the >>> _Unwind_resume() call. GCC emits a call site region for it in the exception >>> table. We...kind of do that. It looks like it's being included in one of the >>> "this is a region which isn't in a try-catch block, but it has a call in it, >>> so lets add it to the exception...

Here's an interesting problem - is it legal to copy the _Unwind_Exception struct to a different address in memory before calling _Unwind_Resume? I'm thinking of the scenario in which a garbage collection run is triggered in the middle of a "finally" block. If it's a copying collector, it might relocate the exception object, which has the _Unwind_Exception structure embedded in the middle of it. I don't see why this w...

...0; } void bar() { try { foo(); } catch (...) { throw 0; } } int main() { try { bar(); } catch (...) { return 0; // fail to catch exception thrown by bar } return 0; } , and the assembly of bar looks like bar: .cfi_def_cfa_offset 16 epilogue​ ​ _Unwind_Resume​ The lookup phase of exception handling ​is fine. However, something goes wrong in cleanup phase. The reason is the unwinder evaluates CFI directives until _Unwind_Resume, and `.cfi_def_cfa_offset 16` is the culprit. I think this is what you were saying "have an epilogue in the middle of a...

I have this project that I can't see how to boil down into a cut down illustration of the problem as it requires a large 3rd party library (ITK www.itk.org), and the problem is actually triggered in that library. But here is the problem: If you compile ITK and the program, it will segfault in _Unwind_resume at the end of a class method. If you build with GCC (4.6.1 in this case) the program passes all regression tests. In gdb, it's really difficult to see what's going on. For one thing it looks like CLang++ is rearranging code even if the -g flag is given -- the execution cursor jumps aroun...

On Mar 6, 2011, at 11:01 AM, Talin wrote: > Here's an interesting problem - is it legal to copy the _Unwind_Exception struct to a different address in memory before calling _Unwind_Resume? > > I'm thinking of the scenario in which a garbage collection run is triggered in the middle of a "finally" block. If it's a copying collector, it might relocate the exception object, which has the _Unwind_Exception structure embedded in the middle of it. I don't see...

...> doing this would not hurt Ada :) > > now I think about it further, I guess SawPotentiallyThrowing is not > for > this exactly, you'll need to add some additional logic near this > place. > Yeah. The logic will need tweaking for sure. I'm also concerned about the _Unwind_resume() call. GCC emits a call site region for it in the exception table. We...kind of do that. It looks like it's being included in one of the "this is a region which isn't in a try-catch block, but it has a call in it, so lets add it to the exception table" areas. If I impleme...

On Sun, Mar 6, 2011 at 7:37 PM, John McCall <rjmccall at apple.com> wrote: > On Mar 6, 2011, at 11:01 AM, Talin wrote: > > Here's an interesting problem - is it legal to copy the _Unwind_Exception > struct to a different address in memory before calling _Unwind_Resume? > > > > I'm thinking of the scenario in which a garbage collection run is > triggered in the middle of a "finally" block. If it's a copying collector, > it might relocate the exception object, which has the _Unwind_Exception > structure embedded in the middle...

On 16 January 2018 at 13:41, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > bar: > > .cfi_def_cfa_offset 16 > epilogue > > _Unwind_Resume > > > > The lookup phase of exception handling is fine. However, something goes > wrong in cleanup phase. The reason is the unwinder evaluates CFI directives > until _Unwind_Resume, and `.cfi_def_cfa_offset 16` is the culprit. I think > this is what you were saying "have a...

...>> >> Actually the existing "unwind" instruction can be repurposed for this, as there >> was no real need for rewind to take any arguments. All that is needed is that >> unwind be lowered to a call of eh.exception, which is then passed as the >> argument to _Unwind_Resume, In fact codegen already does this! > > I'm unhappy about how this bakes _Unwind_Resume into the backend, particularly > since that prevents us from using better alternatives when they're available > (e.g. the ARM EH ABI's _cxa_end_cleanup(), which saves code size by not re...

Hi Bill, > Yeah. The logic will need tweaking for sure. I'm also concerned about > the _Unwind_resume() call. GCC emits a call site region for it in the > exception table. We...kind of do that. It looks like it's being included > in one of the "this is a region which isn't in a try-catch block, but it > has a call in it, so lets add it to the exception table" areas. i...

...{ try { b(); } catch (float f) {} } The landing pad in b() only has one case to worry about, so it's naturally going to immediately enter the catch handler for 'int'. This is obviously semantically wrong if the combined invoke unwinds there. 2. It would need to rewrite calls to _Unwind_Resume on cleanup-only paths if the enclosing invoke has a handler. The EH machinery does not expect a landing pad which claims to handle an exception to just call _Unwind_Resume before handling it; that's why we currently have to use hacks to call _Unwind_Resume_or_Rethrow instead. Also, some plat...

...ptr>,<i32> > > Actually the existing "unwind" instruction can be repurposed for this, as there > was no real need for rewind to take any arguments. All that is needed is that > unwind be lowered to a call of eh.exception, which is then passed as the > argument to _Unwind_Resume, In fact codegen already does this! I'm unhappy about how this bakes _Unwind_Resume into the backend, particularly since that prevents us from using better alternatives when they're available (e.g. the ARM EH ABI's _cxa_end_cleanup(), which saves code size by not requiring the excepti...

...pecifically a runtime function, the behavior is different. For example, suppose the IR contains a call to "llvm.memcpy", and the generated code eventually calls "memcpy". Or suppose the IR contains a "resume" instruction, and the generated code eventually calls "_Unwind_Resume". In this case, the choice is different: lld always chooses the "memcpy" or "_Unwind_Resume" from the shared library, ignoring the order the files are specified on the command-line. Is this the expected behavior? -Eli -------------- next part -------------- An HTML attac...

...all i32 (i8*, i8*, ...)* @llvm.eh.selector.i32( i8* %eh_ptr, i32 (...)* @__gxx_personality_v0, i8* A) %eh_typeid = tail call i32 @llvm.eh.typeid.for.i32( i8* A ) %tmp15 = icmp eq i32 %eh_select, %eh_typeid br i1 %tmp15, label %bb, label %Unwind ... Unwind: ; preds = %lpad tail call i32 (...)* @_Unwind_Resume( i8* %eh_ptr ) unreachable ... } define void @_Z1hv() { entry: invoke void @_Z1gv( ) to label %UnifiedReturnBlock unwind label %lpad ... lpad: ; preds = %entry %eh_ptr = tail call i8* @llvm.eh.exception( ) %eh_select = tail call i32 (i8*, i8*, ...)* @llvm.eh.selector.i32( i8* %eh_ptr, i32...

Hi, On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson <Matthew.Malcomson at arm.com> wrote: > > Hello again, > > I have been thinking more about the GCC implementation of hwasan and > found a few more questions that I would really appreciate help with. > > --- > I've noticed a match-all condition in the compiler inline > instrumentation, but can't see

...fall through, throw, etc. In the case where we failed to catch an > exception in the inner try block, but the outer try block has a catch > handler for that exception, the finally block needs to jump to the outer > landing pad. There are three ways this could happen: > > 1) Call _Unwind_Resume, using an "invoke" IR instruction whose unwind > block points to the outer landing pad. This seems like it would be > expensive however. You need to be very careful with _Unwind_Resume. Due to a change in libgcc (starting from gcc-4.3) you can only use _Unwind_Resume on an excep...

...entry=28 '\034', base=base at entry=0, p=p at entry=0x7fffe8a06020 <error: Cannot access memory at address 0x7fffe8a06020>, val=val at entry=0x7fffffffd6d8) at /build/gcc/src/gcc/libgcc/unwind-pe.h:252 #1 0x00007fffeba05a61 in binary_search_single_encoding_fdes (pc=0x7fffeba04426 <_Unwind_Resume+54>, ob=0x0) at /build/gcc/src/gcc/libgcc/unwind-dw2-fde.c:908 #2 search_object (ob=ob at entry=0x60400001d9d0, pc=pc at entry=0x7fffeba04426 <_Unwind_Resume+54>) at /build/gcc/src/gcc/libgcc/unwind-dw2-fde.c:977 #3 0x00007fffeba05fdd in _Unwind_Find_registered_FDE (bases=0x7fffffffda78,...

Hi Andrew, > pthread_cleanup_pop() is nothing special, it's just an example of a > cleanup handler. Cleanups are very similar to exception handlers, but > with one small difference: they do some work and then call > _Unwind_Resume() which continues unwinding. The unwinder itself > doesn't know anything about pthread cleanups, it just executes > whatever is at the landing pad. cleanups are turned into invoke + (cleanup code) + _Unwind_Resume by llvm-gcc. Ciao, Duncan.