[kaffe] Re: Classpath's doubleToLongBits

Andrew Haley aph at redhat.com
Thu Feb 21 05:45:15 PST 2008


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.





More information about the kaffe mailing list