_darwin10_Unwind_FindEnclosingFunction

[Bryce McKinlay <bmckinlay at gmail dot com>]

libgcc_s and libgcj contain a hack which renames
_Unwind_FindEnclosingFunction to
_darwin10_Unwind_FindEnclosingFunction on darwin targets. It appears
this was introduced to work around an issue in OS X 10.6 where the
_Unwind_FindEnclosingFunction was implemented as a stub which called
abort(). see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991

This has since been fixed in OS X 10.7+, and the system's
_Unwind_FindEnclosingFunction now works.

In Mac OS X 10.7 and 10.8, libgcc_s is installed as a symlink to libSystem:

$ ls -l /usr/lib/libgcc_s.1.dylib
lrwxr-xr-x 1 root wheel 17 Jun 19 13:16 /usr/lib/libgcc_s.1.dylib ->
libSystem.B.dylib

Unfortunately this means that libgcj does not work on a standard Mac
OS X installation, because dyld will see the symlink and resolve
libgcc_s to libSystem before it checks anywhere else:

$ gcj Hello.class --main=Hello
$ ./a.out
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: __darwin10_Unwind_FindEnclosingFunction
  Referenced from: /usr/local/lib/libgcj.13.dylib
  Expected in: /usr/lib/libSystem.B.dylib
 in /usr/local/lib/libgcj.13.dylib
Trace/BPT trap: 5

This can be worked around by adjusting the system library path, or
forcing libgcc_s to be loaded with DYLD_INSERT_LIBRARIES, but libgcj
should work out-of-the-box for without having to hack the dyld
configuration - so clearly we should not be renaming
_Unwind_FindEnclosingFunction on OS X 10.7+ configurations.

But I'm not convinced that this solution was ever really right to
begin with. Even on a 10.6 system, things ought to work so long as you
ensure libgcc_s is loaded before libSystem. Shouldn't the
_darwin10_Unwind_FindEnclosingFunction rename be removed entirely?

Bryce