From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17139 invoked by alias); 11 Aug 2010 12:32:10 -0000 Received: (qmail 17100 invoked by uid 48); 11 Aug 2010 12:32:08 -0000 Date: Wed, 11 Aug 2010 12:32:00 -0000 Message-ID: <20100811123208.17099.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "iains at gcc dot gnu dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2010-q3/txt/msg00015.txt.bz2 ------- Comment #44 from iains at gcc dot gnu dot org 2010-08-11 12:32 ------- I do not think the current solution is complete/correct. For 4.5.x and current trunk we still have a significant problem. (4.4.x apparently still works, as of 4.4.5/r163091, at least for trivial cases) [apollo is i686-darwin9 with r163091 bootstrapped and installed; CWD=build-top-level]. apollo:gcc-4-5-branch-build$ /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw gcj-4.5: Internal error: Abort trap (program ecj1): FAILS apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc /GCC/gcc-4-5-install/bin/gcj-4.5 ../tests/HelloWorld.java --main=HelloWorld -o hw .................................................^^^^^^^^^^^^^^^^^^^^ OK - builds... try to invoke the generated exe: apollo:gcc-4-5-branch-build./hw ... a long wait ... (on powerpc-darwin9 .. you get some interesting error messages about repeated allocation of 1Gb memory chunks :/). Abort trap apollo:gcc-4-5-branch-build$ DYLD_LIBRARY_PATH=gcc ./hw Hello, World Incidentally, this applies equally if one starts from HelloWorld.class It seems to me that we have some dependancy issue that is causing libgcj to link (some) symbols from /libgcc_s.1dylib that should really be linked from /usr/lib/libgcc_s.1.dylib - i.e. the unwinder is being invoked in two different libs :( see **** ========= 4.6-trunk behaves the same on Darwin9, I've not tried Darwin10 (for reasons which should be evident below). ========= Taking the case of Darwin9/OSX 10.5: (a) the code for _Unwind_FindEnclosingFunction &c. as posted on http://www.opensource.apple.com/release/mac-os-x-1058/ is the same as fsf-gcc (AFAICT from browsing it online) -- so I'm not sure why we added in the darwin10_Unwind_FindEnclosingFunction (it's the same code as already present in the system lib). [having said that, even if the system code _is_ broken and unusable, (b) applies. and one needs to work around the breakage without bypassing said system code] (b) As the design(s) stand, we can only have one unwinder.. the choices are: 1/ to use the system one in which case you can integrate your code with system-supplied libraries [which is what, I suspect, the majority of users want] 2/ You can replace the system unwinder with the one in /libgcc_s.1.dylib - in which case you must point DYLD to that before invoking any code generated by gcj (including the compiler itself). That code cannot use _any_ system facilities that might require the unwinder. (ergo, the test-suite passes, but one can't build a general application using arbitrary system facilities). it seems we have (2) at present, and I wonder how useful that is to the majority of end users? (I guess there is also option (3) -> overwrite the system libgcc_s with the one .. but, if you do that, then you must take responsibility for any other system breakage or security issues you cause ... not a route I'd recommend for most end-users ;)). ========= **** Incidentally, this is the whole reason we implemented the libgcc_ext.dylib --- so that extensions to gcc (like emutls) could be applied to OSX without interfering with the unwinder ;) .. and that is the reason that both /usr/lib/libgccs.1.dylib _and_ /libgcc_s.1.dylib are linked into darwin executables, (taking advantage of the different namespaces). However, in this case, if I regress the darwin10_Unwind_FindEnclosingFunction change out, the code still fails - which indicates to me that: (i) somewhere else in the build of libgcj or the classpath there is a dependency on some part of the unwinder that is being satisfied by a link from /libgcc_s.1dylib (although a look at the Makefile didn't show anything obvious, perhaps someone more familiar with libjava would be able to spot it?). (ii) or.. that there's a bug/incompatibility between the system unwinder & fsf gcc that we haven't worked around. in the case of (ii) the endgame is much the same as for darwin 10 .... ========= For Darwin10/OSX10.6 (a) I'm not sure that the current libjava design applies; it seems that the relevant routines might have been replaced by no-ops (from comments posted elsewhere, and a quick check of otool -tv -p _Unwind_FindEnclosingFunction). I.E the unwinder has changed to a different implementation.. However, as for darwin9, (b) applies - one can "replace" the system unwinder with the one in libgcc - but, again, that means the user will be limited to self-contained code. ===== If no-one has time to implement an integration of libjava with the Darwin 10 unwinders [and/or fix the breakage with Darwin9] (I don't, sorry), then essentially gcj > 4.5 is unusable on current Darwin in any other manner than stand-alone (and, frankly, I wonder how generally useful that is?). -- iains at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrs at gcc dot gnu dot org, | |iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991