search for: _unwind_context

...nwind_ForcedUnwind(_Unwind_Exception *exception_object, ^ C:/Users/clang/libunwind/src/UnwindLevel1.c:428:1: warning: redeclaration of '_Unwind_GetLanguageSpecificData' should not add 'dllexport' attribute [-Wdll-attribute-on-redeclaration] _Unwind_GetLanguageSpecificData(struct _Unwind_Context *context) { ^ C:/Users/clang/libunwind/include\unwind.h:270:5: note: previous declaration is here _Unwind_GetLanguageSpecificData(struct _Unwind_Context *context); ^ C:/Users/clang/libunwind/src/UnwindLevel1.c:449:1: warning: redeclaration of '_Unwind_GetRegionStart' should not add...

On 8/29/07, Bill Wendling <isanbard at gmail.com> wrote: > On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > > Hello, Bill > > > > > It may be my lack of understanding, but it appears that having -- > > > enable-eh set during compilation of llvm-gcc is causing extra files > > > to be compiled. > > Oh, no. They are always

...this work is to modify the exception personality function to capture information about the stack. Unfortunately, none of my experiments in this area have yielded anything useful. For example, I have experimented with calling _Unwind_Backtrace from the personality function, but this only yields an _Unwind_Context pointer which is of limited use. It's hard to tell because most of the structures are opaque, but it appears as though the information I'm getting from _Unwind_Backtrace has little or no relation to the state of the stack at the time the exception was actually thrown. It may be that what I...

...unwinding. I guess you are saying we need to move > the unwinders symbols out into a libgcc_ext and use that in the > linkage on 10.6 or later so the FSF unwinder is used instead of > the system one? > Jack The important thing is that only one unwinder is used. The _Unwind_Context data structure is different between the darwin and FSF implementations, so you can't pass it between two different implementations. Since darwin uses two-level namespace and swapping in a new libgcc_s.dylib at runtime is not going to effect the various OS dylibs that are looking for _...

On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: > So, when these test cases are run, is the binary linked against /usr/ > lib/libgcc_s.10.5.dylib? or against some just built libgcc_s.10.5.dylib? > or against some just build libgcc_s.dylib? If either of the latter, then > if you changed the FSF build of libgcc_s for darwin to have the right > magic symbols, then

...c lives in a separate repository these days): Index: gcc/unwind-dw2.c =================================================================== --- gcc/unwind-dw2.c (revision 124749) +++ gcc/unwind-dw2.c (working copy) @@ -1526,7 +1526,7 @@ static inline _Unwind_Ptr uw_identify_context (struct _Unwind_Context *context) { - return _Unwind_GetIP (context); + return _Unwind_GetCFA (context); } I'm uncertain of the merit of this patch, but it's in shipping Leopard and works with gcc, so we're stuck with it. The effect of this is that llvm's strategy of making every C++ selector c...

...; preds = %.try_body > %9 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] > store i8* %9, i8** %.ex_value > %10 = call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8* %9, i8* bitcast (i32 (i32, i32, i64, %struct._Unwind_Exception*, %struct._Unwind_Context*)* @__l_personality to i8*)) ; <i64> [#uses=1] I think you'll need a "i8* null" at the end of this @llvm.eh.selector.i64 call. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100121...

...s): Yuck :) > Index: gcc/unwind-dw2.c > =================================================================== > --- gcc/unwind-dw2.c (revision 124749) > +++ gcc/unwind-dw2.c (working copy) > @@ -1526,7 +1526,7 @@ > static inline _Unwind_Ptr > uw_identify_context (struct _Unwind_Context *context) > { > - return _Unwind_GetIP (context); > + return _Unwind_GetCFA (context); > } > > I'm uncertain of the merit of this patch, but it's in shipping > Leopard and works with gcc, so we're > stuck with it. Right, this is effectively part of the dar...

...ad: ; preds = %.try_body %9 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] store i8* %9, i8** %.ex_value %10 = call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8* %9, i8* bitcast (i32 (i32, i32, i64, %struct._Unwind_Exception*, %struct._Unwind_Context*)* @__l_personality to i8*)) ; <i64> [#uses=1] %11 = icmp eq i64 %10, 0 ; <i1> [#uses=1] %12 = select i1 %11, i64 0, i64 1 ; <i64> [#uses=1] store i64 %12, i64* %.ex_type br label %.finally_handler .finally_handler:...

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote: > > The important thing is that only one unwinder is used. The > _Unwind_Context data structure is different between the darwin and FSF > implementations, so you can't pass it between two different > implementations. Since darwin uses two-level namespace and swapping in > a new libgcc_s.dylib at runtime is not going to effect the various OS > dylibs that...