Native calling on x86_64 *nix gcc

Started by
77 comments, last by WitchLord 15 years, 2 months ago
This is the valgrind log for a run of all the tests in the latest SVN revision (362) after changing new[] to malloc(): http://pastebin.com/m537cb3b0

I think I know how to fix one of them, I'll post an updated 'as_callfunc_x64_gcc.cpp' soon

// moments later:
Ok, here is a new version of 'as_callfunc_x64_gcc.cpp': http://pastebin.com/m379d3ec8

It fixes this valgrind-detected problem:
==10404== Invalid write of size 8==10404==    at 0x4C5181: CallSystemFunction(int, asCContext*, void*) (as_callfunc_x64_gcc.cpp:616)==10404==    by 0x47FA0D: asCContext::ExecuteNext() (as_context.cpp:2044)==10404==    by 0x483E2B: asCContext::Execute() (as_context.cpp:1096)==10404==    by 0x4A223F: asCScriptEngine::ExecuteString(char const*, char const*, asIScriptContext**, unsigned int) (as_scriptengine.cpp:2501)==10404==    by 0x452A10: TestVector3_2::Test() (test_vector3_2.cpp:130)==10404==    by 0x404DE8: main (main.cpp:250)==10404==  Address 0x641da70 is 8 bytes inside a block of size 12 alloc'd==10404==    at 0x4C23CFE: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)==10404==    by 0x464DD9: MyAllocWithStats(unsigned long, char const*, int) (utils.cpp:93)==10404==    by 0x496FD3: asCScriptEngine::CallAlloc(asCObjectType*) (as_scriptengine.cpp:2994)==10404==    by 0x4C44B7: CallSystemFunction(int, asCContext*, void*) (as_callfunc_x64_gcc.cpp:290)==10404==    by 0x47FA0D: asCContext::ExecuteNext() (as_context.cpp:2044)==10404==    by 0x483E2B: asCContext::Execute() (as_context.cpp:1096)==10404==    by 0x4A223F: asCScriptEngine::ExecuteString(char const*, char const*, asIScriptContext**, unsigned int) (as_scriptengine.cpp:2501)==10404==    by 0x452A10: TestVector3_2::Test() (test_vector3_2.cpp:130)==10404==    by 0x404DE8: main (main.cpp:250)
Advertisement
All the warnings about the conditional jumps depending on uninitialized values seems to be 'false positives'. I think that valgrind may be wrong with these.

It may be that the optimization made by the C++ compiler is fooling valgrind a bit. According to valgrind's manual it is recommended to compile the application with -O0 (no optimazation) to avoid valgrind reporting false errors.



I'll investigate the 'invalid read of size 4' problem. I think valgrind have really found a bug here. A bug that probably only happens with the removal of dynamic configuration groups (which few are likely to do) thus going unnoticed until now.

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

I've fixed the memory leak in as_callfunc_x64_gcc.cpp. It was caused by the CallSystemFunction not deleting the object that AngelScript sent by value as it should. This in turn was because the as_callfunc_x64_gcc.cpp doesn't support passing non-complex types by value, because of the very high complexity of having to split the object into separate registers based on the type of each member in the object.

To fix this AngelScript needs to know the exact memory layout of the type. I may add this support in a future version, but for now AngelScript will just report an error when the application tries to register a function that takes these types by value.

I've also fixed the other memory errors that Valgrind reported, i.e. the conditional jumps based on uninitialized memory. These really were uninitialized memory though it was a bit difficult to find.

Valgrind discovered another memory leak that I've yet to look into though. Hopefully I'll be able to take care of it tomorrow.

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

The last memory leak has now been fixed. The as_callfunc_x64_gcc wasn't releasing the autohandles properly.

Valgrind is now reporting 0 errors while running the test_features app. I think we can now safely say that AngelScript supports native calling conventions on 64bit Linux.


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

Hooray! :)

Edit: btw, don't forget to remove the debugging flags in the makefile ;)
Done! Thanks! :)

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

Quote:Original post by WitchLord
The last memory leak has now been fixed. The as_callfunc_x64_gcc wasn't releasing the autohandles properly.

Valgrind is now reporting 0 errors while running the test_features app. I think we can now safely say that AngelScript supports native calling conventions on 64bit Linux.

This is great news indeed :D
Looking forward to actually using the library now ;) Expect n00b questions soon.
In fact, both jal_ and me represent the warsow development team here, we've already released a version at our forums containing the WIP version of AS with native x64 support included. If we encounter any bugs, we'll report back to you :) Thanks!
Ah, that's great. I knew someone on your team was looking into 64bit support, but I didn't remember who it was.

I've added Warsow to the users list. When I buy a new computer I'll give the game a go as well. ;)

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

This topic is closed to new replies.

Advertisement