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...
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
