Linux i686 and x86-64

namtabmai · 2009-02-08T14:06:17

Hi, I'm trying to get Angelscript running on Linux, both on 32bit and 64bit, but without much luck at the moment. I'm currently running the latest SVN version as of yesterday, but I've tried before with the stable version with unsuccessful results. There are some issues with compiling on both platforms, firstly the in atomic.cpp. Looks like you've used a kernel header for your asCAtomic class which is a bit of a no-no according to the kernel developers, these functions/headers are only really meant to be used inside the kernel. I've changed it to use gcc built in atomic functions which seems to work o.k. for the few tests that do pass at the moment. See below for the changes. #include <asm/atomic.h> BEGIN_AS_NAMESPACE asDWORD asCAtomic::atomicInc() { return atomic_inc_and_test(value); } asDWORD asCAtomic::atomicDec() { return atomic_dec_and_test(value); } #include <asm/atomic.h> asDWORD asCAtomic::atomicInc() { return __sync_fetch_and_add(&value, 1); } asDWORD asCAtomic::atomicDec() { return __sync_fetch_and_sub(&value, 1); } I'm using test_feature to check Angelscript performs as expected, but I've had to change a few of the tests in order to get it to compile. The vector3 tests require scriptmath3d, but scriptmath3d needs new.h which I'm guessing is part of the MS CRT library? So for the moment I've just #ifndef __LINUX__ these tests out, perhaps once the rest of the code is working I'll look at trying to get this built as well. On 64bit I've also had to #ifdef out a few of the tests in test_registertype due to them using asCALL_CDECL. Anyway my current fail on 64bit is in test_stringscript testing script3, this seems to stem from the fact in asCContext::CallGeneric currentObject is NULL, so further on in scriptstring.cpp CScriptString::operator= is getting passed NULL for other. I'll do some more digging and see if I can work out the exact cause of this, but perhaps you might be able to point me in the right direction?

_Vicious_

330

February 08, 2009 04:23 AM

oh, right, how could I miss that.. Note that the address gets mangled with AS_MAX_PORTABILITY defined, so my guess is that it's a bug in the VM itself

jal_

122

February 08, 2009 06:17 AM

BTW, the very same thing happens in win64:

Quote:
> game_x64.dll!objectString_Addref(asstring_t * obj=0x01e467a001e467a0) Line 859 + 0xb bytes C
game_x64.dll!objectString_asGeneric_Addref(void * gen=0x000000000012eeb8) Line 864 C
angelwrap_x64.dll!asCScriptEngine::CallObjectMethod(void * obj=0x01e467a001e467a0, asSSystemFunctionInterface * i=0x000000000215ebe0, asCScriptFunction * s=0x000000000217bbd0) Line 2713 C++
angelwrap_x64.dll!asCScriptEngine::CallObjectMethod(void * obj=0x01e467a001e467a0, int func=41) Line 2659 C++
angelwrap_x64.dll!asCContext::ExecuteNext() Line 2308 C++
angelwrap_x64.dll!asCContext::Execute() Line 1096 + 0xa bytes C++
angelwrap_x64.dll!asCModule::CallInit() Line 218 C++
angelwrap_x64.dll!asCModule::Build() Line 170 C++
angelwrap_x64.dll!qasBuildModule(int engineHandle=0, const char * module=0x0000000002cad868) Line 630 C++

Quote:
+ obj 0x01e467a001e467a0 {buffer=??? len=??? asRefCount=??? ...} asstring_t *

EDIT: It's normal that it ends in the non-generic function, because our code uses the generic function just to call the normal function.

[Edited by - jal_ on February 8, 2009 6:17:51 AM]

WitchLord

4,860

February 08, 2009 06:35 AM

Quote:
The problem is that with gcc 3.3.4 the program crashed very soon after AS initialization, disabling multithreading fixed that, hence the second patch.

Did it crash due to asCAtomic, or something else? If it was due to asCAtomic, then perhaps it works if the critical sections are used instead?

I'd prefer not to disable the multithreading support by default. If it is possible to get multithreading working then it should be turned on by default (even if it hurts performance).

I'll add a section in the manual on how to get the most performance out of the library, e.g. by compiling the library with asNO_THREADS.

I'll look into the problem with the 64bit platforms. It's most likely a bad type cast somewhere. The problem is that I don't have a 64bit platform to test this on, but I've asked droz for access to his VPS, so hopefully I should be able to fix this soon enough.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Vicious_

330

February 08, 2009 07:20 AM

Quote: Original post by WitchLord
Quote:
The problem is that with gcc 3.3.4 the program crashed very soon after AS initialization, disabling multithreading fixed that, hence the second patch.

Did it crash due to asCAtomic, or something else? If it was due to asCAtomic, then perhaps it works if the critical sections are used instead?

Here's the backtrace:

#0  0x00000041 in ?? ()#1  0xb7bb9662 in ScriptStructFactory (objType=0x8401ad0, engine=0x83a8fb0) at ../../source/as_scriptstruct.cpp:69#2  0xb7bbf674 in asCArrayObject::Construct (this=0x83ee468, buf=0x8446568, start=0, end=3) at ../../source/as_arrayobject.cpp:452#3  0xb7bbf544 in asCArrayObject::CreateBuffer (this=0x83ee468, buf=0x83ee478, numElements=3) at ../../source/as_arrayobject.cpp:420#4  0xb7bbee23 in asCArrayObject (this=0x83ee468, length=3, ot=0x840c7b0) at ../../source/as_arrayobject.cpp:302#5  0xb7bbe2ef in ArrayObjectFactory2 (ot=0x840c7b0, length=3) at ../../source/as_arrayobject.cpp:56#6  0xb7bd2996 in endcopy () at ../../source/as_callfunc_x86.cpp:565#7  0xb7bd22a3 in CallSystemFunction (id=2, context=0x8410dd8, objectPointer=0x0) at ../../source/as_callfunc_x86.cpp:324#8  0xb7bf9bc0 in asCContext::ExecuteNext (this=0x8410dd8) at ../../source/as_context.cpp:2044#9  0xb7bf834d in asCContext::Execute (this=0x8410dd8) at ../../source/as_context.cpp:1096#10 0xb7c05632 in asCModule::CallInit (this=0x83eee88) at ../../source/as_module.cpp:217#11 0xb7c05415 in asCModule::Build (this=0x83eee88) at ../../source/as_module.cpp:168

jal: figured :)

WitchLord

4,860

February 08, 2009 07:50 AM

I just checked in some changes (rev 354) that I hope fixes both of your problems.

First of all I changed as_atomic.cpp to use critical sections on GCC for versions older than 4.1. This will avoid using the kernel functions altogether, at the price of slower performance. (Remember to turn off multithreading if you don't need it)

I also found a couple of places where the compiler was generating incorrect bytecode for 64bit platforms. Hopefully with these fixes you won't get the SEGV crashes anymore.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Vicious_

330

February 08, 2009 08:54 AM

Thanks! I'll check out the x64 changes asap. As for the atomic stuff, you forgot to add the

		#if !( ( (__GNUC__ == 4) && (__GNUC_MINOR__ >= 1) || __GNUC__ > 4) )			// Only with GCC 4.1 was the atomic instructions available			#define AS_NO_ATOMIC		#endif

section into the

#elif defined(__linux__)

block ;) Not sure if it really belongs to the __APPLE__ one.. After fixing this section, things seem to be working fine again

WitchLord

4,860

February 08, 2009 09:07 AM

Oops. Thanks. I've updated it again.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

_Vicious_

330

February 08, 2009 09:18 AM

Due to the change to the Makefile, linking a library with libangelscript.a produces an error:

/usr/bin/ld: ../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a(as_scriptengine.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../libsrcs/angelscript/angelSVN/sdk/angelscript/lib/libangelscript.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

WitchLord

4,860

February 08, 2009 09:50 AM

I'm not sure what it may be. gargltk has just finished implementing the native support for 64bit Linux and he didn't report this problem.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game