[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9

["iains at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.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