[kaffe] cross-compile error

[Dalibor Topic]

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