Dalibor Topic schrieb:
Dalibor Topic wrote:
Robert Schuster wrote:
Hi.
Dalibor Topic schrieb:
On to the next problem: currently the jit regression test fails at a
floating point test.
The FAQ.arm says:
"From Kaffe's point of view, only 'FPA' is supported right now. Some
effort has been started to use 'VFP', and I hope we can rewrite this
section soon. For jit/jit3 engine, the support of 'FPA' is mandatory
(the internal code generation emits FPA instruction) and if you don't
have FPA (or FPA emulation by the operating system) only possibility
is to use interpreter engine."
I think that this may be the reason for the failing floating point
test.
Debian arm on QEMU uses fpa (hard), so that's not causing the problem
(and libffi does not help, either). It turned out that float to int
conversion of NaNs was broken in some way, so I ripped that code out of
the arm jit engine. Using the soft float to int conversion, the
regression test on the jit engine pass, up to a hang after generating
VMThrowable.fillInStackTrace and the soft_fixup_trampoline returning
a value.
There is a warning related to soft_fixup_trampoline on arm (and it
stretches all along the code use COMPARE_AND_EXCHANGE), so I'll try
to see if using glib's atomic functions helps.
It helps fix the specific warning, but I'd like to take a closer look
at locks.c, that uses COMPARE_AND_EXCHANGE, too, post 1.1.9. It wasn't
the cause of the problem, anyway.
Looking a bit closer at this through gdb, it seems that we end up in an
infinite loop inside the buildStackTrace function when counting the
stack traces. So the next step would be to try to figure out what's
wrong with the exception frame code for arm-linux. My wild guess is
that __builtin_frame_address(0) on gcc 4.1+ rears its ugly head again...
I've played a bit further with this, and now I've got a patch that
changes the buildStackTrace function to
stop counting frames when we start looping frames (happens on
arm-linux-oabi). That fixes the jit test, and
lets all but 27 regression tests pass in jit mode (gcc 4.2, libffi,
etc.). I'll clean it up, and separate it from the
bits that replace COMPARE_AND_EXCHANGE with glib, and commit it.
The EABI jit test fails on returning float constant 0.0, as it gets
0x00000001 back. Any ideas from EABI folks
what may be causing that, and how to go about tracking it down?
My plan would be to look at making the interpreter pass on arm-oabi and
arm-eabi without failures, and then
to move on to the jits. I'd also like to see if I can rip out all the
atomic* code in Kaffe's config dirs by using glib's
atomic functions instead, as that would be less low level code from libc
to keep around as copies in Kaffe.
Any volunteers for the arm-* interpreter failures?
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
