Status report of libjava on *-*-freebsd[45]*

Status report of libjava on *-*-freebsd[45]*

[Loren James Rittle]

Hi all again,

I think I finally understand the root cause of the increase in the
number of libjava test suite failures I saw on i386-unknown-freebsd*
between mid-January and mid-March.  Since I shared earlier trials with
the public list, I thought a write-up was in order.  Since this might
be useful information to you, David, I'm CC'ing you since I can't
imagine that you normally have time to read the java list.

When I bootstrap gcc on i386-*-freebsd* or alpha-*-freebsd* against
FSF binutils 2.12 (prerelease), I see all simple EH libjava examples
break as previously described.  I have run such cases under gdb and
can see that the libjava EH personality routine is not installed
properly.  I assume I have the right technique to look for this
missing registration since when a breakpoint is set in
extract_cie_info(), I could see the personality routine properly
installed when I used a gcj bootstrap against the system copy of
binutils 2.11.2.  Using the same procedure with the example built
against a gcc bootstrapped against FSF binutils 2.12 (prerelease), I
see extract_cie_info() called but never to install the libjava
personality routine.  Oddly, there is no problem for C++ EH (which
also installs an EH personality and uses the same unwind code?).  This
might be related to issues David O'Brien found with updating the
FreeBSD system's copy of binutils to 2.12.  Or, it might be a
completely independent issue.  I have not yet determined exactly what
changed to break this.

When I bootstrap against the system copy of binutils 2.11.2:
GNU ld version 2.11.2 20010719 [FreeBSD] (with BFD 2.11.2 20010719 [FreeBSD])

I see the following libjava testsuite results:

FAIL: Divide_1 execution from source compiled test
FAIL: Divide_1 execution from bytecode->native test
FAIL: Divide_1 -O execution from source compiled test
FAIL: Divide_1 -O execution from bytecode->native test
FAIL: Invoke_1 execution from source compiled test
FAIL: Invoke_1 execution from bytecode->native test
FAIL: Invoke_1 -O execution from source compiled test
FAIL: Invoke_1 -O execution from bytecode->native test
FAIL: PR218 execution from source compiled test
FAIL: PR218 execution from bytecode->native test
FAIL: PR218 -O execution from source compiled test
FAIL: PR218 -O execution from bytecode->native test
WARNING: program timed out.
FAIL: Thread_Join execution from source compiled test
WARNING: program timed out.
FAIL: anonarray execution from bytecode->native test
FAIL: err1 execution from source compiled test
FAIL: Throw_2 execution from source compiled test
FAIL: Throw_2 execution from bytecode->native test
FAIL: Throw_2 -O execution from source compiled test
FAIL: Throw_2 -O execution from bytecode->native test
FAIL: indirect_read execution from source compiled test
FAIL: indirect_read execution from bytecode->native test
FAIL: indirect_write execution from source compiled test
FAIL: inner1 -O execution from source compiled test
FAIL: tmi -O execution from bytecode->native test
FAIL: update_outer execution from source compiled test
FAIL: Array_3 execution from source compiled test
FAIL: Array_3 execution from bytecode->native test
FAIL: Array_3 -O execution from source compiled test
FAIL: Array_3 -O execution from bytecode->native test

		=== libjava Summary ===

# of expected passes		2003
# of unexpected failures	29
# of expected failures		18
# of untested testcases		43

These results look as good as ever reported for this port.  At least
20 of the tests are currently failing because we don't yet implement
MD_FALLBACK_FRAME_STATE_FOR and thus do not allow an EH throw from a
signal handler.

Since I missed the window of getting a patch to enable
MD_FALLBACK_FRAME_STATE_FOR in for gcc 3.1 (at least I assume I have
missed it given the release rules and I'm not sure I'm up to that task
even if not), I am now checking whether the obvious configure.host
tweaking would help us.  As long as I post it very soon, I am still
assuming that a patch that merely specializes the i386-* and alpha*-*
cases of the primary switch in configure.host for particular OSes
would still be acceptable.  OK?

When I rebuilt libjava from scratch with a tweaked configuration (to
be posted to java-patches after I tinker some more ;-) for
i386-*-freebsd4.5, I saw these results:

WARNING: program timed out.
FAIL: G19990304_01 execution from source compiled test [0]
FAIL: InterfaceDispatch -O execution from bytecode->native test
FAIL: err12 execution from bytecode->native test
FAIL: Throw_2 execution from source compiled test [1]
FAIL: Throw_2 execution from bytecode->native test
FAIL: Throw_2 -O execution from source compiled test
FAIL: Throw_2 -O execution from bytecode->native test
FAIL: instinit2 execution from source compiled test [2]
FAIL: instinit2 execution from bytecode->native test
FAIL: pr133 execution from bytecode->native test
WARNING: program timed out.
FAIL: search_outer -O execution from source compiled test [0]
WARNING: program timed out.
FAIL: invokethrow execution from bytecode->native test
FAIL: ArrayStore2 execution from bytecode->native test

[0] Could not reproduce when manually ran the steps from libjava.log.

[1] Based on recent list traffic, I think we have to live with it.

[2] I looked at this failure closely.  Interestingly enough, it
exposes a bug in my configuration of boehm-gc for FreeBSD/i386.  Just
like FreeBSD/alpha, it is possible to build an executable with an
unmapped hole between the end of the initialized data segment and the
start of the BSS on FreeBSD/i386.  While looking at the default linker
script the other day, I knew this was a theoretical possibility but
unlike the alpha, I never saw it in practice on the i386.  It appears
that the gap left between those regions is usually aligned in such a
way that no unmapped space actually exists.  However, just due to the
luck of the draw, parts/all of the gap may be unmapped when the
alignment is just right.

All ``execution from bytecode->native test'' failures, deferred
analysis in the hopes that they go away with the GC fix. ;-)

Regards,
Loren