I'd wager this is the same problem that has been reported for Linux with armel. It's quite possible that RPi uses the same ABI as armel Linux.

The thing is that the ABI is slightly different from that used by iOS, Android, and Windows Phone. It would be necessary to make changes to the as_callfunc_arm_gcc code to support this too.

Do you have any documentation that describes the ABI used by RPi? Or else try to disassemble a function that returns a float value and another that returns an int value so we can examine the difference.

This is common for x86 ABIs, but I'm not sure the ARM has separate registers for int and floats.

Seeing the disassembly of the functions would be helpful. Something simple, for example:


int func1()
{
return 42;
}

float func2()
{
return 3.141592f;
}


Well, it's clear from the disassemblies that the ABI does indeed pass the float type in different registers.

For the int type, the register r0 is used both for passing the value are argument and returning the value. For the float type, the register s0 is used instead.

Based on this knowledge the code in the as_callfunc_arm.cpp and as_callfunc_arm_gcc.S needs to be modified to properly handle the float and double types with this ABI.

The function CallSystemFunctionNative() needs to be updated to prepare the arguments before calling the assembler routines. Either the arguments needs to be separated in two separate arrays, one for integers and one for floats, or the arguments can be kept as is but another array is created that identifies which of the arguments are floats. Then the assembler routines needs to be updated to load the registers correctly based on the arrays.

Before deciding how to implement the management of the argument you should identify how mixed arguments are handled in the ABI. For example, let's say you have a function like this:

void func(int a, float b, int c, float d) {}

We already know a will be placed into r0. But where does the other arguments go? There are two options that I believe are the most probable.

a -> r0, b -> s0, c -> r1, d -> s1

or

a -> r0, b -> s1, c -> r2, d -> s3

It would also be good to know how doubles and int64s are handled. On some platforms they take up 2 registers, and always aligned to an even numbered register, which would mean that you may have to handle skipping some registers in order to align the 64bit arguments.


Unfortunately I will not be able to do the coding myself, as without having the capability to test the code it would be extremely difficult to get it right. If you have time to invest in this should be able to get it to work on your own with a few days of work. It will be a bit of an investigative work to understand how the ABI works, but it's not so difficult if you have the capability to debug and disassemble.

Yes, it would seem that the ABI keeps two distinct arrays, one for floats and one for integers. Integers goes to r0, r1, r2, ..., and floats to s0, s1, s2, ...

If each d, register is in fact two s registers, then it is necessary to consider padding when mixing floats and doubles.

It would be interested to see a receivesMixed2(int a, double b, int c, float d). From what we've seen so far, these arguments should be passed as following: a -> r0, b -> d0, c -> r1, d -> s2. The last goes to s2 because d0 occupies both s0 and s1.

receivesMixed3(float a, double b, float c) should be as following: a -> s0, b -> d1, c -> s4. The last goes to s4, because d1 occupies both s2 and s3. In this case s1 is not used.

Another thing that needs to be checked before the best algorithm can be determined is how many registers that may be used for passing arguments. The iOS and Android ABI only uses 4 registers at most (r0 to r3), the arguments that don't fit into these 4 registers are pushed on the stack.