Re: libjava patches for RTEMS

[Jie Liu <lj8175@gmail.com>]

Hi,
The libjava.sum[1] and libjava.log[2] generated when running libjava
testsuite can be seen on:
[1] http://rtemsgcj.googlecode.com/svn/trunk/gcjtest/testsuite_out/libjava.sum
[2] http://rtemsgcj.googlecode.com/svn/trunk/gcjtest/testsuite_out/libjava.log

Because of the testsuite is running on qemu, 2 failures are caused by
RTEMS hanging when starting on qemu. These two (PR12915.java and
Thread_Join.java) is PASS when I test it manually.
FAIL												After
FAIL: PR12915 execution - source compiled test				PASS
FAIL: Thread_Join -O3 execution - source compiled test		PASS

Almost every case has [compilation|execution|output] x [
|-findirect-dispatch|-O3|-O3 -findirect-dispatch] = 12 results. 6
failures are just one  FAIL of twelve results. The six are:
FAIL																	After
FAIL: PR12656 -findirect-dispatch execution - source compiled test					PASS
FAIL: PR141 -findirect-dispatch execution - source compiled test						PASS
FAIL: PR35020 execution - source compiled test									PASS
FAIL: PR5057 -O3 -findirect-dispatch execution - source compiled test					PASS
FAIL: PR56 -O3 execution - source compiled test									PASS
FAIL: err14 execution - source compiled test									PASS
These six is PASS when I compile them and run them again. In the
manual test, qemu is hanging once without any output(If it is hanging
when RTEMS is starting, there is some output). So, that may be the
same for why it’s FAIL when test automatically.

Many cases are failed in output or execution with all [
|-findirect-dispatch|-O3|-O3 -findirect-dispatch]. There are 20 cases
of this kind of situation and result in 80 failures. I tested it
manually to find why it is FAIL(The manual test in this section with
neither -O3 nor -findirect-dispatch).
FAIL																				After
FAIL: EvaluationOrder output - source compiled test (x4)										PASS
FAIL: LargeFile execution - source compiled test (x4)											PASS
after Modify
FAIL: PR18699 execution - source compiled test (x4)											FALL
FAIL: PR27908 execution - source compiled test (x4)											PASS after Modify
FAIL: Process_1 execution - source compiled test (x4)											UnSupport
FAIL: Process_2 execution - source compiled test (x4)											UnSupport
FAIL: Process_3 execution - source compiled test (x4)											UnSupport
FAIL: Process_4 execution - source compiled test (x4)											UnSupport
FAIL: Process_5 execution - source compiled test (x4)											UnSupport
FAIL: Process_6 execution - source compiled test (x4)											UnSupport
FAIL: Process_7 output - source compiled test (x4)											UnSupport
FAIL: TLtest execution - source compiled test (x4)											FAIL
FAIL: Thread_Alive execution - source compiled test (x4)										PASS
FAIL: Thread_Interrupt output - source compiled test (x4)										FAIL
FAIL: Thread_Sleep output - source compiled test (x4)											PASS
FAIL: Thread_Sleep_2 output - source compiled test (x4)										FAIL
FAIL: Thread_Wait execution - source compiled test (x4)										PASS
FAIL: Thread_Wait_2 execution - source compiled test (x4)										PASS
FAIL: Throw_2 output - source compiled test (x4)												FAIL
FAIL: pr133 output - source compiled test (x4)												PASS
1 EvaluationOrder output failures is caused by I add one more element
for argv[] in the RTEMS system wrap file. The failures are PASS when I
remove the element.
2 LargeFile.java attempts to write “OK” at a new file’s 2G position
and read it out, RTEMS is using memory file system, so the failures
are in forecast. It is PASS when I use a small position number, e.g.
32.
3 PR18699.java is hanging in PR18699.notifyObservers(…), And I have
not find the reason.
4 Process_1 to Process_7, RTEMS does not support dynamically loading
program and run it, such as “sed -e s/Hello/Goodbye/ Hello World”, so
the Process class is not supported on RTEMS.
5 PR27908.java is related to scheduling policy of RTEMS, now it can be
PASS with modifying source code, I will pay more attention to this
case and try to make it pass without any modifying.
6TList.java is hanging when call ThreadLocal.set() or ThreadLocal.get().
7 Thread_Alive.java, Thread_Sleep.java, Thread_Wait, Thread_Wait_2 can
get through when I reconfigured libjava with HAVE_GETTIMEOFDAY and
RTEMS with CONFIGURE_MICROSECONDS_PER_TICK(1000).
8 Thread_Interrupt.java failure result is “Busy wait was not
interrupted”. This may be the problem in RTEMS.
9 Thread_Sleep_2.java: System.nanoTime() is a little less than required.
10 Throw_2.java: Double.parseDouble(null) does not throw NullPointerException.
11 pr133.java is failure before is caused by I send a second argv to
Java, It is PASS when I removed the argv in system wrap file.

FAIL 										After
libjava.jar/TestClosureGC output					PASS
libjava.jar/simple output						PASS
libjava.loader/TestMultiple						UnSupport
libjava.loader/TestParent						UnSupport
libjava.lang/bclink (x2)							FAIL
1TestClosure.java and simple.java is PASS when I test them manually.
2TestMultiple.java and TestParent.java: RTEMS is not support
dynamically loading while they are called “loadClass ("dummy")”.
3 bclink.java : When compiled this with -findirect-dispatch, it will
throw NoClassDefFoundError Exception.

So the actual failures are 27 caused by 6 source file. I will pay more
attentions to this 6 file and make the patch for libjava.
How to mark those unsupported cases as expected failures on *-*-rtems* ?

Best Regards,
Jie


2011/7/6 Andrew Haley <aph@redhat.com>:
> On 05/07/11 17:35, Bryce McKinlay wrote:
>> On Tue, Jul 5, 2011 at 3:14 PM, Andrew Haley <aph@redhat.com> wrote:
>>
>>>> As the testsuite result is good enough, I think it's time to  get the
>>>> patch reviewed and merged into gcc. The patch is attached. :)
>>>
>>> Ah, 94 failures?
>
> Perhaps, but it would be interesting to know why there are so many
> failures, and what they are.  If this is the first stage of a work
> in progress, that's fine, but I hope that some of these will be fixed.
>
> Andrew.
>
>