Displaying 3 results from an estimated 3 matches for "_cxa_".
Did you mean:
cxa_
2009 Sep 18
0
[LLVMdev] OT: intel darwin losing primary target status
...unwinder.
So it seems to me you should be testing the compiler against the OS
unwinder - not against the just built unwinder.
Has something changed in the FSF unwinder that clients of gcc will want?
-Nick
P.S. One minor pet peeve of mine is that the exception handling is
well layered (e.g. _cxa_* layer on top the _Unwind_* layer (which on
darwin is now built upon the libunwind layer)). Except for one
glaring problem. The compiler mostly emits calls to _cxa_* functions,
but it makes one call to _Unwind_Resume. Ah!! And those are in
different dylibs! If instead the compiler ma...
2009 Sep 18
4
[LLVMdev] OT: intel darwin losing primary target status
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
2009 Sep 18
2
[LLVMdev] OT: intel darwin losing primary target status
...ould be testing the compiler against the OS
> unwinder - not against the just built unwinder.
>
> Has something changed in the FSF unwinder that clients of gcc will want?
>
> -Nick
>
> P.S. One minor pet peeve of mine is that the exception handling is well
> layered (e.g. _cxa_* layer on top the _Unwind_* layer (which on darwin is
> now built upon the libunwind layer)). Except for one glaring problem.
> The compiler mostly emits calls to _cxa_* functions, but it makes one
> call to _Unwind_Resume. Ah!! And those are in different dylibs! If
> instead...