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 / as
board description file for target.
Using / as generic
interface file for target.
Using / as
tool-and-target-specific interface file.
Running /
cni.exp
Running /
compile.exp
Running /
jacks.exp
Running /
jar.exp
Running /
jni.exp
Running /
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 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
Running /
loader.exp
Running /
mauve.exp
Running /
verify.exp
libjava Summary
# of expected passes 3794
# of unexpected failures 10
# 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

Sandro Tolaini writes:

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:

K, so the only things now failing are the tests that rely on throwing
exceptions from signal handlers. Make sure that the line

can_unwind_signal=no

is present under i[34567]86darwin in libjava's configure.host.

Andrew.

19/mar/2006, at 12:21, Andrew Haley wrote:

K, so the only things now failing are the tests that rely on throwing
exceptions from signal handlers. Make sure that the line

can_unwind_signal=no

is present under i[34567]86darwin in libjava's configure.host.

Yes, it's present. If I set can_unwind_signal=yes much more tests fail.

Cheers,
Sandro

Sandro Tolaini writes:

19/mar/2006, at 12:21, Andrew Haley wrote:

K, so the only things now failing are the tests that rely on throwing
exceptions from signal handlers. Make sure that the line
>
can_unwind_signal=no
>
is present under i[34567]86darwin in libjava's configure.host.

Yes, it's present. If I set can_unwind_signal=yes much more tests fail.

K. Well, if I were doing this I'd start with Array_3, running it
under gdb to see where it goes wrong.

Andrew.

Andrew Haley wrote:
Sandro Tolaini writes:

19/mar/2006, at 12:21, Andrew Haley wrote:

K, so the only things now failing are the tests that rely on throwing
exceptions from signal handlers. Make sure that the line

can_unwind_signal=no

is present under i[34567]86darwin in libjava's configure.host.

Yes, it's present. If I set can_unwind_signal=yes much more tests fail.

K. Well, if I were doing this I'd start with Array_3, running it
under gdb to see where it goes wrong.

I'd say this is missing:

MD_FALLBACK_FRAME_STATE_FR

see , darwin-unwind.h, darwin.h

Andreas

Andreas Tobler writes:
Andrew Haley wrote:
Sandro Tolaini writes:

19/mar/2006, at 12:21, Andrew Haley wrote:

K, so the only things now failing are the tests that rely on throwing
exceptions from signal handlers. Make sure that the line
>
can_unwind_signal=no
>
is present under i[34567]86darwin in libjava's configure.host.

Yes, it's present. If I set can_unwind_signal=yes much more tests fail.

K. Well, if I were doing this I'd start with Array_3, running it
under gdb to see where it goes wrong.

I'd say this is missing:

MD_FALLBACK_FRAME_STATE_FR

see , darwin-unwind.h, darwin.h

Why would that matter? It's not used becasue there is no handler
installed.

Andrew.