* _darwin10_Unwind_FindEnclosingFunction
@ 2012-07-23 11:24 Bryce McKinlay
2012-07-26 13:44 ` _darwin10_Unwind_FindEnclosingFunction Jack Howarth
0 siblings, 1 reply; 2+ messages in thread
From: Bryce McKinlay @ 2012-07-23 11:24 UTC (permalink / raw)
To: gcc, java, Jack Howarth
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: _darwin10_Unwind_FindEnclosingFunction
2012-07-23 11:24 _darwin10_Unwind_FindEnclosingFunction Bryce McKinlay
@ 2012-07-26 13:44 ` Jack Howarth
0 siblings, 0 replies; 2+ messages in thread
From: Jack Howarth @ 2012-07-26 13:44 UTC (permalink / raw)
To: Bryce McKinlay; +Cc: gcc, java, mikestump, iains
On Mon, Jul 23, 2012 at 12:23:59PM +0100, Bryce McKinlay wrote:
> 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
The following works fine here using a gcc trunk built on 10.8...
howarth% gcc-fsf-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.8
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.8/libexec/gcc/x86_64-apple-darwin12.0.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12.0.0
Configured with: ../gcc-4.8-20120725/configure --prefix=/sw --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
Thread model: posix
gcc version 4.8.0 20120725 (experimental) (GCC)
howarth% cat testme.java
public class testme {
public static void main(String args[]){
System.out.println("Hello");
}
}
howarth% gcj-fsf-4.8 --main=testme -O testme.java
howarth% ./a.out
Hello
>
> 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?
If I recall correctly, Apple added some magic to make sure that the symbols
previously in libgcc_s would always be resolved from libSystem. I can dig
out the email traffic on that with the darwin linker developer later. Since
10.6 would remain broken, if 10.7/10.8 no longer needs the hack we would
still have to use that hack when targeting darwin10. Iain Sandoe made the
last adjustment to this hack...
2010-08-17 Iain Sandoe <iains@gcc.gnu.org>
* include/posix.h: Make substitution of
_darwin10_Unwind_FindEnclosingFunction conditional on
OSX >= 10.6 (Darwin10).
Perhaps we can expand it to OSX >= 10.6 and < 10.7? Note that the unwinder situation
is pretty ugly because from 10.6 onwards we are using a compatibility unwinder and
not really the unwinder from libgcc in FSF gcc. Only a single unwinder can be used
and it should always be the system unwinder. The compatibility unwinder doesn't use
FDEs and over aggressively set aborts to functions like _Unwind_FindEnclosingFunction.
Apple may well have removed the aborts for those calls (although they probably are still
effectively no-ops).
Jack
>
> Bryce
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-07-26 13:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-23 11:24 _darwin10_Unwind_FindEnclosingFunction Bryce McKinlay
2012-07-26 13:44 ` _darwin10_Unwind_FindEnclosingFunction Jack Howarth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).