search for: _urc_continue_unwind

Hi Garrison, > Yes. The issue here, as you pointed out, is that your personality > function is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still > be called. this is not correct. Unwind_RaiseException will just exit without unwinding the stack if all personality functions return _URC_CONTINUE_UNWIND. Ciao, Duncan.

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed could affect this), _Unwind_RaiseException(...) is not being called, or the default or another personality function (_gcc_personality_...

Hi Duncan, Yes, but the personality function will get called in order for it to return _URC_CONTINUE_UNWIND. When I said "it", I meant the personality function in its search phase not the cleanup/handler phase. I believe, if I understand correctly, Jame's personality function is not being called during the search phase. If this is not case, and his personality function is called during the...

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

Hi Chris, The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the associated personality's first unwind search phase, which happens to have no language specific context, and is returning a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem is obvious to you. One way to reproduce this in trunk from root...

...t; >> Hi Chris, >> >> The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the >> associated personality's first unwind search phase, which happens to have no language specific context, and is returning >> a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then >> this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem >> is obvious to you. One way to reproduce this i...

..., Garrison Venn wrote: > Hi Chris, > > The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the > associated personality's first unwind search phase, which happens to have no language specific context, and is returning > a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then > this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem > is obvious to you. One way to reproduce this in trunk...

...10/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either dwarf exception header info is not > emitted (llvm::DwarfExceptionHandling = true; > not executed could affect this), _Unwind_RaiseException(...) is not being > called, or the default or another personality >...

...Chris, >>> >>> The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the >>> associated personality's first unwind search phase, which happens to have no language specific context, and is returning >>> a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then >>> this wasn't seen in one of the test cases. Anyway just wanted to give a heads up as I'm studying this, just in case the problem >>> is obvious to you. One way to reproduc...

...ons. A C++ catch-all will happily catch Ada exceptions for example. If there is a C++ cleanup and an Ada exception is unwinding then (assuming the Ada exception isn't matched by a C++ catch-all) the C++ personality function acts exactly the same as if a C++ exception was unwinding: it returns _URC_CONTINUE_UNWIND and the unwinder continues to unwind. Let's suppose that there are only cleanups all the way up the stack. Then phase 1 ends with _Unwind_RaiseException returning _URC_END_OF_STACK. If it was C++'s "throw" that was doing the unwinding, it will terminate the program at this poin...

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi Garrison, > > > %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* >> @_Unwind_RaiseException to i8* (...)*)(i64* %6) >> to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] >> >> I am not sure this is going to work, at least from the way I've played >> with

...10/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either dwarf exception header info is not > emitted (llvm::DwarfExceptionHandling = true; > not executed could affect this), _Unwind_RaiseException(...) is not being > called, or the default or another personality >...

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

Hi Garrison, > %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* > @_Unwind_RaiseException to i8* (...)*)(i64* %6) > to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] > > I am not sure this is going to work, at least from the way I've played > with the system. > In my examples the _Unwind_RaiseException(...) is called from a