Sign in to follow this  
droz

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
droz    134
Quote:
Original post by WitchLord
Probably 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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this