This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
- From: "iains at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 11 Aug 2010 12:32:08 -0000
- Subject: [Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
- References: <bug-41991-11113@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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 <fsf>/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
<fsf-path>/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
<fsf> 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_
<fsf>/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
<fsf>/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