# Native calling config for more BSD platforms

## Recommended Posts

droz    134
I finally got around to testing some additional BSD platforms, and they work just fine with the same config for FreeBSD:

#elif defined(__FreeBSD__) || defined(__DragonFly__) || defined(__OpenBSD__)

I haven't been able to test NetBSD, having issues getting it to work in qemu. However OpenBSD is based on it, and it should work fine. I will try to get it tested soon.

I'm also working on getting native calling working on Linux using ARM processors. So far TestScriptString fails, still running the tests with that one skipped to see what else (if any) fails.

Update: All other tests pass.

##### Share on other sites
WitchLord    4678
Thanks. I've added this configuration to the SVN (rev 725)

Any idea why the TestScriptString fails on Linux/ARM? What kind of error do you get?

##### Share on other sites
droz    134
I don't get any error message, just says "One of the tests failed, see details above.". I just got home from work and plan to step through it with gdb.

##### Share on other sites
droz    134
I know the first place it fails is here (line 246):
	printOutput = "";	ExecuteString(engine, "print(\"a\" + 1.2)");	if( printOutput != "a1.2") fail = true;

Tomorrow I will have some time, and will be able to investigate some more.

##### Share on other sites
WitchLord    4678
Probably the constant 1.2 is formatted differently in the string for some reason.

##### Share on other sites
droz    134
I've been busy and haven't gotten a chance to really see whats happening. When I get a some free time I will try to figure out why it's failing.

##### Share on other sites
droz    134
Quote:
 Original post by WitchLordProbably the constant 1.2 is formatted differently in the string for some reason.

You are correct, the string contains:
a8.81144e-308

The next check in that test adds 1.2 + "a", that ends up being:
5.30084e-315a

Any idea as to why this would happen?

##### Share on other sites
droz    134
This test passes when using max portability So either it's a difference between the CPU that I'm compiling for, and what the native calling was tested on. Or this is a bug across all arm platforms that no one has noticed?

I assume it's the first one, but unfortunately I don't own a android or iphone to run the tests. I guess my next step will be to install the android emulator to see if the test passes on it.

##### Share on other sites
WitchLord    4678
It's possible that this scenario hasn't been tested on other ARM devices with Linux.

The functions that are being called are (from add_on/scriptstring):

static CScriptString *AddStringDouble(const CScriptString &str, double f){	char buf[100];	sprintf(buf, "%g", f);	return new CScriptString(str.buffer + buf);}static void AddStringDouble_Generic(asIScriptGeneric *gen){	CScriptString *str = (CScriptString*)gen->GetObject();	double f = gen->GetArgDouble(0);	CScriptString *out = AddStringDouble(*str, f);	gen->SetReturnAddress(out);}static CScriptString *AddDoubleString(double f, const CScriptString &str){	char buf[100];	sprintf(buf, "%g", f);	return new CScriptString(buf + str.buffer);}static void AddDoubleString_Generic(asIScriptGeneric *gen){	double f = gen->GetArgDouble(0);	CScriptString *str = (CScriptString*)gen->GetObject();	CScriptString *out = AddDoubleString(f, *str);	gen->SetReturnAddress(out);}

As you can see the generic function is just a wrapper for the native function.

The problem seems to be with arguments of the type double in as_callfunc_arm.cpp or as_callfunc_arm_GCC.S.