Dalibor Topic wrote:
Christian Thalinger schrieb:
On Fri, 2008-02-08 at 12:25 +0100, Dalibor Topic wrote:
Yeah, that's why I'd like to go step by step, and first slash the
VM interface methods I can slash, and then implement it with
ieee754.h as an option, (adding a #define BIG_ENDIAN __BIG_ENDIAN
for the broken glibc versions). I'll make sure to post the native
patches for comments first, as I don't have access to a VFP box.
OK, I hope I still have access to this box, but I'll try to test them.
This one turned out to be a lot more fun to track down.
It's pretty easy to rewrite the test whether to swap words in a
jdouble: put -0.0 into a jvalue's jdouble element, and if the
correspoding jlong bitstream is > 0, you have to swap the words.
It's a way of dynamically doing what the fdlibm #defines do, but it
works out the same way: swap on arm-debian-oabi.
But that didn't fix the breakage.
So I played around some more, and eventually, it turned out that
kaffe's classfile constant parser was working fine, and I was
reading in doubles the way arm's FPU expected them laid out, it
turned out the interpreter was working ok, too, and so on.
But the breakage was still there.
Turning the way, for example, the double constants were parsed
around, and doing it the 'wrong' way, fixed some regression tests,
but broke others. Similarly, reassembling doubles in the interpreter
from words the 'wrong' way had the same effect with other tests.
So I had to examine things a bit more closely with jcf-dump. It
turned out that, since I was using a glibj.zip compiled on an
x86-linux host, the constant in the class java.lang.Double were laid
out correctly. But in the tests classes compiled on the
arm-oabi-linux platform using ecj on gcj-4.3, double constants were
laid out incorrectly, with their words swapped, as a comparison with
the tests compiled on x86-linux with ecj on gcj showed.
Do we need a gcj fix somewhere?
Andrew.
