From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20697 invoked by alias); 26 Jul 2012 13:44:56 -0000 Received: (qmail 20677 invoked by uid 22791); 26 Jul 2012 13:44:54 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_GC,TW_LR,TW_RW,TW_WX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jul 2012 13:44:40 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id D9707B004B; Thu, 26 Jul 2012 09:44:39 -0400 (EDT) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id q6QDidKv012103; Thu, 26 Jul 2012 09:44:39 -0400 Date: Thu, 26 Jul 2012 13:44:00 -0000 From: Jack Howarth To: Bryce McKinlay Cc: gcc@gcc.gnu.org, java@gcc.gnu.org, mikestump@comcast.net, iains@gcc.gnu.org Subject: Re: _darwin10_Unwind_FindEnclosingFunction Message-ID: <20120726134439.GA12052@bromo.med.uc.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2012-07/txt/msg00001.txt.bz2 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 * 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