http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01
00:14:17 UTC ---
(In reply to comment #3)
> we keep going round this loop --- by making this change; you are replacing the
> unwinder in libSystem with the one in FSF libgcc_s.
Why do you say that? I am returning the linkage to...
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
/Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
which if anything should insure that the system unwinder related calls are used
rather
than those in the FSF libgcc_s. Please reread...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html
My understanding from this was that the system unwinder was protected by magic
symbols
and would ALWAYS be used. However by putting /usr/lib/libgcc_s.1.dylib back in
front of /Users/howarth/dist/lib/libgcc_s.1.dylib, we may be insuring that any
other
unprotected unwinder related symbols come from the Apple's libgcc and not FSF
libgcc.
I think at this point that the important question is where do we have
demonstrated breakage.
I don't recall we ever had an explicit example demonstrating that the remaining
change in
r163267 was essential.
