Porting gcj to i386-darwin
Hi everyone, I would like to port gcj/libgcj to i386-darwin. Is there someone already working on that? Considering that powerpc-darwin is a supported platform, it should not prove to be too hard. However, I need some hints on how to proceed. At configure phase, GCC woes for: target-libmudflap target-libffi target-boehm-gc target-zlib target-libjava target-libada gnattools target-libgfortran The last 3 items should not really be needed for gcj. Let examine the others: target-zlib: should be sufficient to add i386-darwin to the supported platforms target-boehm-gc: a patch exists for porting to the new platform, so it should be a matter of applying it target-libffi, target-libmudflap, target-libjava: I don't know what exactly needs to be done, maybe someone could help me Another question: if I change a configure.am somewhere, is there a script that rebuilds all the configure things or I have to call autoconf (which version?) on it? Cheers, Sandro smime.p7s Description: S/MIME cryptographic signature
Re: Porting gcj to i386-darwin
On 10/mar/2006, at 20:42, Tom Tromey wrote: libffi and mudflap were covered by Paolo and Andrew. I have done some work on sysv.S and now libffi compiles fine on OSX/ Intel. Unfortunately, I had to put some #ifdef __APPLE__ this file because Apple ships an old cctools with as that doesn't understand some directives. My patch works on the 4.0 branch, I tried it on the 4.2 branch but libffi has changed in such a way that compiling it with the Apple as is not easily feasible (and I don't chew enough assembly code to change it). For libjava some porting may be required, though it shouldn't be very much. libjava compiled out-of-the-box after tweaking the configure scripts. For boehm, I copied the one in the 4.2 branch and applied a patch that Hans should have already put in the current CVS version. For best results you will want to make sure that the code to turn signals into exceptions works properly. This is both OS- and architecture dependent. I haven't looked at the x86 darwin port, perhaps some gcc hacking is required. How can I try this? Is there some test case I can use? Considering all of the above facts, how can I submit a patch, and how much likely it is to be accepted? Anyway, I'm very happy because I can finally use my MacBook Pro for development: our software has a key component that is written in C++ and Java and needs to be compiled in native code, with this patch everything seems to work fine :) Cheers, Sandro smime.p7s Description: S/MIME cryptographic signature
Re: Porting gcj to i386-darwin
On 11/mar/2006, at 02:09, Tom Tromey wrote: Yes, one of the test cases in the libjava test suite checks this. Offhand I forget which one... but if you do a 'make check' and send the list of FAILs we can help analyze them. (This would be better done on the gcj list, [EMAIL PROTECTED]) This is the result of make test in the libgcj directory. There are some unexpected failures, as you can see: Test Run By sandro on Sat Mar 11 07:42:56 2006 Native configuration is i686-apple-darwin8.5.2 === libjava tests === Schedule of variations: unix Running target unix Using /Users/sandro/staging/share/dejagnu/baseboards/unix.exp as board description file for target. Using /Users/sandro/staging/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/sandro/gcc-4.0.2/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.cni/ cni.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.compile/ compile.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jacks/ jacks.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jar/ jar.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jni/ jni.exp ... FAIL: PR15133 execution - gij test FAIL: cxxtest execution - gij test FAIL: directbuffer execution - gij test FAIL: martin execution - gij test FAIL: noclass execution - gij test FAIL: pr11951 run FAIL: throwit execution - gij test Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.lang/ lang.exp ... FAIL: ArrayStore execution - gij test FAIL: ArrayStore execution - gij test FAIL: Array_3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 execution - bytecode->native test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 execution - gij test FAIL: Array_3 -O3 execution - bytecode->native test FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 execution - bytecode->native test FAIL: Divide_1 -O3 execution - source compiled test FAIL: Divide_1 -O3 execution - bytecode->native test FAIL: FileHandleGcTest execution - gij test FAIL: FileHandleGcTest execution - gij test FAIL: Invoke_1 execution - source compiled test FAIL: Invoke_1 execution - bytecode->native test FAIL: Invoke_1 -O3 execution - source compiled test FAIL: Invoke_1 -O3 execution - bytecode->native test FAIL: PR218 execution - source compiled test FAIL: PR218 execution - gij test FAIL: PR218 execution - bytecode->native test FAIL: PR218 -O3 execution - source compiled test FAIL: PR218 execution - gij test FAIL: PR218 -O3 execution - bytecode->native test FAIL: Process_5 execution - gij test FAIL: Process_5 execution - gij test FAIL: Process_6 execution - gij test FAIL: Process_6 execution - gij test FAIL: StringBuffer_1 execution - gij test FAIL: StringBuffer_1 execution - gij test FAIL: StringBuffer_overflow execution - gij test FAIL: StringBuffer_overflow execution - gij test FAIL: String_overflow execution - gij test FAIL: String_overflow execution - gij test FAIL: Thread_Alive execution - gij test FAIL: Thread_Alive execution - gij test FAIL: Thread_Interrupt execution - gij test FAIL: Thread_Interrupt execution - gij test FAIL: Thread_Wait_2 execution - gij test FAIL: Thread_Wait_2 execution - gij test FAIL: Thread_Wait_Interrupt execution - gij test FAIL: Thread_Wait_Interrupt execution - gij test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 execution - bytecode->native test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 execution - bytecode->native test FAIL: instinit2 execution - gij test FAIL: instinit2 execution - gij test FAIL: invokethrow execution - source compiled test FAIL: invokethrow execution - gij test FAIL: invokethrow execution - bytecode->native test FAIL: invokethrow -O3 execution - source compiled test FAIL: invokethrow execution - gij test FAIL: invokethrow -O3 execution - bytecode->native test Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.loader/ loader.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.mauve/ mauve.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.verify/ verify.exp ... === libjava Summary === # of expected passes3687 # of unexpected failures63 # of expected failures 14 # of untested testcases 79 smime.p7s Description: S/MIME cryptographic signature
Re: Patch for i386-darwin: test suite results
On 17/mar/2006, at 00:57, Andrew Pinski wrote: Actually it looks like libffi is still not working as you no longer have eh info for x86-darwin. This is why all the gij tests fail. I have implemented EH for Darwin/x86 and now much more tests pass: Test Run By sandro on Sun Mar 19 10:12:14 2006 Native configuration is i686-apple-darwin8.5.2 === libjava tests === Schedule of variations: unix Running target unix Using /Users/sandro/staging/share/dejagnu/baseboards/unix.exp as board description file for target. Using /Users/sandro/staging/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/sandro/gcc-4.0.2/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.cni/ cni.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.compile/ compile.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jacks/ jacks.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jar/ jar.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.jni/ jni.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.lang/ lang.exp ... FAIL: Array_3 execution - gij test FAIL: Array_3 execution - gij test FAIL: PR218 execution - gij test FAIL: PR218 execution - gij test FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 execution - bytecode->native test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 execution - gij test FAIL: Throw_2 -O3 execution - bytecode->native test Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.loader/ loader.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.mauve/ mauve.exp ... Running /Users/sandro/gcc-4.0.2/libjava/testsuite/libjava.verify/ verify.exp ... === libjava Summary === # of expected passes3794 # of unexpected failures10 # of expected failures 14 # of untested testcases 26 Here are the current patches needed to build gcc 4.0.2 with java support (note that boehm-gc needs to be updated to 6.7, patches are not included here). Cheers, Sandro gcc-top.diff Description: Binary data libffi.diff Description: Binary data libjava.diff Description: Binary data
Forward port darwin/i386 support 4.0 => 4.2 problems
I have successfully forward ported libffi changes from 4.0 to 4.2, but I have some problems running the testsuite. Here are the results: # of expected passes1052 # of unexpected failures8 # of unsupported tests 8 Looking at the failures, I have: FAIL: libffi.call/return_fl2.c -O0 -W -Wall execution test FAIL: libffi.call/return_fl2.c -O2 execution test FAIL: libffi.call/return_fl2.c -O3 execution test FAIL: libffi.call/return_fl2.c -Os execution test These all fail for a dummy FP rounding problem: the output is always "1022.800049 vs 1022.800018", so I'm leaving these alone (should the tests be fixed somehow?). The other 4 failures are here: FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test These all fail because of this: dyld: Symbol not found: ___dso_handle Referenced from: /Users/sandro/t/i386-apple-darwin8.5.2/./libstdc+ +-v3/src/.libs/libstdc++.6.dylib Expected in: flat namespace libjava testsuite has a similar problem when test programs are being run: dyld: Symbol not found: _GC_gcj_debug_kind Referenced from: /Users/sandro/t/i386-apple-darwin8.5.2/./ libjava/.libs/libgcj.7.dylib Expected in: flat namespace I'm attaching the patch against a current svn checkout. Anyone has some ideas on how to fix these problems? Cheers, Sandro gcc42-libffi.diff Description: Binary data gcc42-libjava.diff Description: Binary data gcc42-top.diff Description: Binary data
Re: Forward port darwin/i386 support 4.0 => 4.2 problems
On 24/mar/2006, at 10:50, Sandro Tolaini wrote: I'm attaching the patch against a current svn checkout. Forgot to say that boehm-gc needs to be upgraded to 6.7. I've not included patches for this, simply import it from the original distribution. Cheers, Sandro smime.p7s Description: S/MIME cryptographic signature
Boehm GC memory leak on Darwin
This has been discussed and patched on the gc mailing list. I think that incorporating the patch is mandatory for all the 4.x branches: http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-December/ 001071.html Cheers, Sandro
Re: Forward port darwin/i386 support 4.0 => 4.2 problems
On 24/mar/2006, at 14:24, Andrew Pinski wrote: This looks like you did not update your cctools to the newest one which was posted which includes this symbol. Updated cctools, now the not found symbol has changed: dyld: _dyld_bind_fully_image_containing_address() error dyld: Symbol not found: __Unwind_GetIPInfo Referenced from: /Users/sandro/t/i386-apple-darwin8.5.2/./ libjava/.libs/libgcj.7.dylib Expected in: flat namespace Any suggestion? I did a full bootstrap after upgrading cctools. Cheers, Sandro
GCJ on Darwin/i386 patches
Finally, I managed to fix up libffi and run testing on libjava under
Darwin/i386.
Here is the libffi testsuite output:
Test Run By sandro on Sun Mar 26 10:49:37 2006
Native configuration is i386-apple-darwin8.5.2
=== libffi tests ===
Schedule of variations:
unix
Running target unix
Using /opt/local/share/dejagnu/baseboards/unix.exp as board
description file for target.
Using /opt/local/share/dejagnu/config/unix.exp as generic interface
file for target.
Using /Users/sandro/gcc-4.2/libffi/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /Users/sandro/gcc-4.2/libffi/testsuite/libffi.call/call.exp ...
FAIL: libffi.call/return_fl2.c -O0 -W -Wall execution test
FAIL: libffi.call/return_fl2.c -O2 execution test
FAIL: libffi.call/return_fl2.c -O3 execution test
FAIL: libffi.call/return_fl2.c -Os execution test
Running /Users/sandro/gcc-4.2/libffi/testsuite/libffi.special/
special.exp ...
=== libffi Summary ===
# of expected passes1060
# of unexpected failures4
# of unsupported tests 8
The failures are due to a floating point rounding problem, not to
libffi itself.
Here is libjava testsuite output:
Test Run By sandro on Sat Mar 25 22:59:33 2006
Native configuration is i386-apple-darwin8.5.2
=== libjava tests ===
Schedule of variations:
unix
Running target unix
Using /opt/local/share/dejagnu/baseboards/unix.exp as board
description file for target.
Using /opt/local/share/dejagnu/config/unix.exp as generic interface
file for target.
Using /Users/sandro/gcc-4.2/libjava/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.cni/cni.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.compile/
compile.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.jacks/
jacks.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.jar/jar.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.jni/jni.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.lang/
lang.exp ...
XPASS: PR26858 execution - source compiled test
XPASS: PR26858 output - source compiled test
XPASS: PR26858 execution - bytecode->native test
XPASS: PR26858 output - bytecode->native test
XPASS: PR26858 -O3 execution - source compiled test
XPASS: PR26858 -O3 output - source compiled test
XPASS: PR26858 -O3 execution - bytecode->native test
XPASS: PR26858 -O3 output - bytecode->native test
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 -O3 execution - bytecode->native test
FAIL: initexc execution - gij test
FAIL: initexc execution - gij test
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.loader/
loader.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.mauve/
mauve.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.special/
special.exp ...
Running /Users/sandro/gcc-4.2/libjava/testsuite/libjava.verify/
verify.exp ...
=== libjava Summary ===
# of expected passes4055
# of unexpected failures8
# of unexpected successes 8
# of expected failures 12
# of untested testcases 18
The failures are due to the missing signal unwinding code (something
that is out of my reach at the moment, so we must live with it at the
moment unless someone is willing to write this part). The unexpected
passes are a mistery to me :)
There is currently a problem in libjava testsuite execution:
{builddir}/gcc dir is not added to the ld_library_path, so I had to
manually set it in the environment in order to let the executables
find the right libgcc_s shared library. Moreover, you have to apply
the already posted patch to include the __Unwind_GetIPInfo symbol in
the libgcc_s library. I'm attaching this patch for your convenience.
I tested a full bootstrap on Darwin/i386. Newer cctools are required
(590.36).
I'd like to see these patches checked in on the gcc trunk. I also
have backported patches for 4.0 branch, if maintainers are willing to
incorporate them (keep in mind that in the 4.0 branch boehm-gc needs
to be synced to the trunk version before applying these patches).
Cheers,
Sandro
gcc42-boehm-gc.diff
Description: Binary data
gcc42-gcc.diff
Description: Binary data
gcc42-libffi.diff
Description: Binary data
gcc42-libjava.diff
Description: Binary data
gcc42-top.diff
Description: Binary data
Boehm GC memory leak on Darwin
I'm sending this note again since I have been caught in this bug once more. Under Darwin (PPC and Intel) there is a serious memory leak at every Boehm GC cycle. See discussion and patch here: http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-December/ 001071.html I think that the patch should be applied to every maintained branch. Please maintainers, check this in! Cheers, Sandro Tolaini
Re: RFC: x86 Linux stack alignment requirement
On 07/giu/2006, at 18:22, H. J. Lu wrote: The x86 psABI is very old and doesn't cover XMM registers. I'd like to update x86 Linux calling convention for XMM register usage. I am not sure if I should update stack alignment requirement. Maybe you'll want to check how this is handled in Darwin/x86, which requires 16-byte stack alignment because it is internally using XMM registers. Cheers, Sandro
