[kaffe] cross-compile error

[Dalibor Topic]

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