It should be received as a double. The script will call the 'bool get(const string &in, double&out) const' overloaded method on the dictionary object. The C++ method will receive a pointer to a double that it will fill with the value. Then the script will convert that double to a float and assign it to the f variable.

That gives me an idea of the problem. When you check if a parameter is a float or double, do you also check to make sure it is not a reference? I.e. !descr->parameterTypes[n].IsReference()?

If the argument is a reference, it should be treated as a integer as it is the address that is being passed to the function, not the float value.

I think this was my mistake, I forgot to tell you about checking for references earlier.

Added the check for references, and the seg fault is gone! I still have some tests that fail and the GC still complaints about not being able to release an object of type "_builtin_function_" after the serializer test is passed.

The tests that are still failling are:

TestScriptString
TestRegisterType
TestVector3
TestStdString

Can you see anything in common between these tests?

The TestCompiler is also crashing - what´s more, this one even crashes the app but I have a very good idea of what´s wrong and how ti fix it.

I´ll begin by looking at the TestScriptString. It fails here:

ExecuteString(engine, "print(1.2 + \"a\")");
if( printOutput != "1.2a")
{
printf("Get '%s'\n", printOutput.c_str());
TEST_FAILED;
}

Does it manage to print something? What does it print? As the test shows, the expected output is "1.2a", what did you get?

The test will call the following registered function:


static CScriptString *AddFloatString(float f, const CScriptString &str)
{
char buf[100];
sprintf(buf, "%g", f);
return new CScriptString(buf + str.buffer);
}


So it should pass the float f in s0, the string pointer str in r0, and then return the new string pointer in r0. Is this what is happening?

The function is registered with asCALL_CDECL_OBJLAST, so perhaps that may be the reason for the failure.

All of the tests that fail actually test a lot of different functionality, so I need to know on which particular test that they fail on. The best would be if you can tell me the line number where the test is reporting that it is failing. Then I can have a look at the code and try to think of what can be wrong.

Regards,
Andreas

This test first calls (ICC_CDECL)

string@ _string_factory_(const int, const uint8&)

Returns an object, and the calls (ICC_CDECL_OBJLAST)

string@ string::opAdd_r(double) const

This also returns an object. Then it prints:

Get '11.8998a'
Failed on line 254... (which is the last line of the code I copied in my previous post)

Yes. It's clear that the problem is that the function didn't receive the correct value on the float argument.

It would appear that armFuncObjLast is not working properly. It's setting the string pointer in the r0 register as it should, but it is not setting s0 with the float value as it should.

s0? Shouldn´t it be d0, since it´s a double?

Yes, you're right. My mistake. Sorry about that.

It should be a double, and it should be d0. The function that will be called is the AddDoubleString() and not the AddFloatString() as I said before.

I found something. In the as_callfunc_arm_gcc.S file, armFuncObjLast function begins and ends like this:


armFuncObjLast:
stmfd sp!, {r4-r8, r10, lr}

// Magic begins....
.......


blx r4
fstmiad r10, {d0-d7} // Copy contents of registers d0-d10 to the address stored in r10
add sp, sp, r8 // sp += r8 sets sp to its original value

str sp, [r10, #68] // store final sp value - for checks only, should be taken out in finalcode

ldmfd sp!, {r4-r8, r10, pc}




This doesn´t work for the TestScriptString test. But if I change:


armFuncObjLast:
stmfd sp!, {r4-r8, r10, lr}


To this:


armFuncObjLast:
stmfd sp!, {r4-r8, r10, r11, lr}


(With the corresponding change to the epilog) then the test passes! Is this some kind of alignment problem?

It could be. I see you had originally added r10, to the stmfd instruction. By now adding r11 as well, the instruction would maintain the 8 byte alignment.

Does this change break anything else? Otherwise I'd suggest you leave it like this (just put a comment so we can remember why r11 is being backed up too).

I guess this makes it clear:

"The ARM-THUMB Procedure Call Standard

The new ATPCS requires that sp always points to 8-byte boundaries. Your assembly language code must preserve 8-byte alignment of the stack at all external interfaces."