Displaying 3 results from an estimated 3 matches for "__cxa_resume".
2009 Sep 18
0
[LLVMdev] OT: intel darwin losing primary target status
...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 made some call like
__cxa_resume() in libstdc++.dylib which turned around and called
_Unwind_Resume() in libgcc_s.dylib, then much of the problem above
would never happen.
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
...(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 made some call like __cxa_resume() in
> libstdc++.dylib which turned around and called _Unwind_Resume() in
> libgcc_s.dylib, then much of the problem above would never happen.
>
I am not sure if some of these problems were latent and only
exposed by the change, but the mass regressions in the g++
and libjava testsuites...