• Advertisement
Sign in to follow this  

Native calling config for more BSD platforms

This topic is 2684 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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


Link to post
Share on other sites
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
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
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
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
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
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
Sign in to follow this  

  • Advertisement