[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
> 
> http://opensource.apple.com/tarballs/libunwind/

To be clear,

For OSX 10.4 (Darwin8) and 10.5 (Darwin9) libgcc is derived from gcc sources
(4.0.1) which are incompatible/buggy when combined with unwinder changes made
during 4.5.  The compact unwinder is not present and there is no need to
consider it at all.  

For OSX 10.6 (Darwin 10), the libgcc functionality has been pulled into
libSystem.dylib (and, I assume, is derived from BSD or other  sources).  IIRC,
the 10.6 compact unwinder issues are to do with the library used by ld64 to
build such code.  FSF-gcc does not produce compact unwinder code on 10.6, and
the non-compact variant works (at least insomuch as the test-suite passes).

So the only places that we need to "fix" things in order to have a working
unwinder are 10.4 and 10.5:

What matters there is having a FAT libgcc_s.dylib that supports the corrected
'normal' unwinder.  This can be achieved by building libgcc_s from recent (say
4.8) sources.  The only consideration then is whether one is prepared to
replace the Apple-provided version of libgcc_s with one that you've built
yourself.

FWIW, I'd be happy to provide FAT library builds tested on 10.5 (I run three
PPC and an X86 box with 10.5).  I'd also be happy to provide a version for 10.4
- although that might take longer as I have to drag old hardware out of storage
to test it.  Personally, I have replaced the Apple-provided libgcc_s.dylib on
my Quad G5 and and 10.5 Xeon and Core2 boxen without issues - the FAT version
must include PPC(7400) on X86 if one wants to use rosetta.  I just build it
4-ways [i386, x86_64, ppc, ppc64] and use the same lib on x86 and ppc.

However I have nowhere appropriate to host the libraries - and the
responsibility for replacing the Apple-provided library absolutely needs to be
in the hands of the end user.

Note that 10.5 and 10.4 no longer get security updates, and it is possible to
arrange symbolic links to libgcc_s versions such that the Apple version could
be reinstated quickly if necessary - of course all of this requires sudo and
terminal work, but Id assume that anyone building GCC from source should be
able to cope with that.

It really doesn't seem productive to hold 10.5 (at least) at an older unwinder
- but if someone really wants to update the 4.6 patch on this thread to match
the scheme now used for 4.7/4.8/trunk, I'd be happy to review.