Okay, here's the output this time:
AngelScript options: AS_64BIT_PTR AS_WIN AS_X64_GCC
-- TestExecute passed
-- TestCDeclReturn passed

TestExecute1Arg: testVal is not of expected value. Got 0, expected 5

Failed on line 50 in ../../source/testexecute1arg.cpp

TestExecute1Arg: testVal is not of expected value. Got 0, expected 5

Failed on line 83 in ../../source/testexecute1arg.cpp

got a couple of warnings while compiling the source code too (although I think they're irrelevant to my problem):

x86_64-w64-mingw32-g++ -I/home/porkbot/build/mingw-w64/include -ggdb -I../../../../angelscript/include -Wno-missing-field-initializers -o obj/test_getset.o -c ../../source/test_getset.cpp
../../source/test_getset.cpp: In function 'bool TestGetSet::Test()':
../../source/test_getset.cpp:1218:60: warning: invalid access to non-static data member 'TestGetSet::CNode::vector' of NULL object
../../source/test_getset.cpp:1218:60: warning: (perhaps the 'offsetof' macro was used incorrectly)
../../source/test_getset.cpp:1219:53: warning: invalid access to non-static data member 'TestGetSet::CNode::vector' of NULL object
../../source/test_getset.cpp:1219:53: warning: (perhaps the 'offsetof' macro was used incorrectly)

x86_64-w64-mingw32-g++ -I/home/porkbot/build/mingw-w64/include -ggdb -I../../../../angelscript/include -Wno-missing-field-initializers -o obj/scriptfile.o -c ../../../../add_on/scriptfile/scriptfile.cpp
../../../../add_on/scriptfile/scriptfile.cpp: In function 'void RegisterScriptFile_Native(asIScriptEngine*)':
../../../../add_on/scriptfile/scriptfile.cpp:201:78: warning: invalid access to non-static data member 'CScriptFile::mostSignificantByteFirst' of NULL object
../../../../add_on/scriptfile/scriptfile.cpp:201:78: warning: (perhaps the 'offsetof' macro was used incorrectly)
../../../../add_on/scriptfile/scriptfile.cpp: In function 'void RegisterScriptFile_Generic(asIScriptEngine*)':
../../../../add_on/scriptfile/scriptfile.cpp:234:78: warning: invalid access to non-static data member 'CScriptFile::mostSignificantByteFirst' of NULL object
../../../../add_on/scriptfile/scriptfile.cpp:234:78: warning: (perhaps the 'offsetof' macro was used incorrectly)
[/quote]

The good thing is that at least the functions are called, so the code is not completely wrong for MinGW64.

Now it's necessary to figure out why the argument wasn't received properly in the test that failed. The code in as_callfunc_x64_gcc.cpp will put the integer argument in the RDI CPU register, but it seems that MinGW64 is following a different convention. It is quite probable that MinGW64 is using the Microsoft calling convention in order to be better compatible with Windows dlls. In this case the first argument should be passedin the RCX register instead. (You can see this in the as_callfunc_x64_msvc_asm.asm file).

Can you show me the disassembly of the cfunction? It would help in determining how the argument should be passed.

If we see that MinGW64 follows the MSVC Win64 convention, then it's necessary to change the code in AngelScript to use that instead. The good thing is that the MSVC convention is really simple compared to what GNUC uses on Linux, so it should be quite easy to do. You can probably change the code to use as_callfunc_x64_msvc.cpp without much changes, and then just adapt as_callfunc_x64_msvc_asm.asm to assembly code that MinGW understands. I suggest inlining it in the as_callfunc_x64_msvc.cpp itself (similar to as_callfunc_x64_gcc.cpp) so it isn't necessary to have a separate assembler file for MinGW64. Observe that the GetReturnedFloat() and GetReturnedDouble() from as_callfunc_x64.gcc.cpp can probably be reused, so you don't have to convert these from Microsoft assembler.


You may ignore the compiler warnings you got. GNUC doesn't like the use of the macro 'offsetof', but it works as is should so there is no problem with it.

Can you show me the disassembly of the cfunction? It would help in determining how the argument should be passed.
[/quote] What "cfunction" exactly do you mean?

Sorry I wasn't clear enough.

I meant the 'static void cfunction(int f1)' that you find in the file test_feature/source/testexecute1arg.cpp on line 14. This is the function that is being called but that doesn't receive the correct value in the argument. If the disassambly of this function shows that it reads the argument value from the RCX register, then we can pretty much assume that MinGW64 is following the MSVC calling convention.

If only it were that simple.. I don't have a 64bit debugger here, the machine the binary is compiled on is a 64bit linux system.

If I'm not mistaken, I believe there is a command line option for the gcc compiler, and therefore also mingw to output the assembler instead of the object file.

[EDIT] I found a post on google on this. Maybe you can give it a try? How to output assembler with gcc.

Thanks, here's the asm code:
.LFE821:
.lcomm _ZL7testVal,4,4
.lcomm _ZL6called,1,1
.text
.def _ZL9cfunctioni; .scl 3; .type 32; .endef
_ZL9cfunctioni:
.LFB842:
.file 2 "../../source/testexecute1arg.cpp"
.loc 2 15 0
pushq %rbp
.LCFI10:
movq %rsp, %rbp
.LCFI11:
movl %ecx, 16(%rbp)
.loc 2 16 0
movb $1, _ZL6called(%rip)
.loc 2 17 0
movl 16(%rbp), %eax
movl %eax, _ZL7testVal(%rip)
.loc 2 18 0
leave
.LCFI12:
ret


Looks like I'm correct. It is the ECX (lower half of RCX) that holds the value that is eventually put in the testVal variable.

The hard part will now be to convert the code from the CallX64 MSVC assembler code in as_callfunc_x64_msvc_asm.asm into something that MinGW64 can compile. The syntax for inline assembler in GNUC is a bit weird and I do not have much experience with it, but I believe the code in as_callfunc_x86.cpp will serve as a good comparison for how to write it. Remember that the order of the arguments to the assembler instructions are the inverse compared to the MSVC assembler style.

Ok, here's my first stab at it: http://e4m5.net/as_c...c_x64_mingw.cpp

AngelScript version: 2.21.0
AngelScript options: AS_64BIT_PTR AS_WIN
-- TestExecute passed
--- Assert failed ---
func: void ExecuteString()
mdle: ExecuteString
sect: ExecuteString
line: 1
---------------------

TestReturn: cfunction didn't return properly

Failed on line 82 in ../../source/test_cdecl_return.cpp
Failed on line 244 in ../../source/test_cdecl_return.cpp[/quote]

It's a good start. You were able to successfully call a global function without corrupting the callstack. And the return of floats and doubles seems to work.

There is trouble with returning boolean and integer types though. So this needs to be studied.

In the inline assembler there is no need to manually implement the prolog and epilogue, i.e. the pushing and popping of all the registers. The compiler will do that for you, if you just tell it which registers are used. You do that after the third :.

The following article might be of use: GCC-Inline-Assembly-HOWTO


In fact I think you got the operands for the inline assembly wrong. I'll admit that I don't fully understand them myself, but I believe that after the first : you list the output values, after the second : you list the input, and after the third you list all the registered that are changed (but are not part of the input/output).

My guess is that you want something like this:


static asQWORD CallX64(const asQWORD *args, const asQWORD *floatArgs, int paramSize, asQWORD func)
{
asQWORD ret = 0;

__asm__ __volatile__ (
"# Move function param to non-scratch register\n"
" mov %4,%%r14 # r14 = function\n" // Copy func into r14
"# Allocate space on the stack for the arguments\n"
"# Make room for at least 4 arguments even if there are less. When\n"
"# the compiler does optimizations for speed it may use these for \n"
"# temporary storage.\n"
" mov %3,%%rdi\n" // Copy paramSize into rdi
" add $32,%%rdi\n"
"# Make sure the stack pointer is 16byte aligned so the\n"
"# whole program optimizations will work properly\n"
"# TODO: optimize: Can this be optimized with fewer instructions?\n"
" mov %%rsp,%%rsi\n"
" sub %%rdi,%%rsi\n"
" and $0x8,%%rsi\n"
" add %%rsi,%%rdi\n"
" sub %%rdi,%%rsp\n"
"# Jump straight to calling the function if no parameters\n"
" cmp $0,%3 # Compare paramSize with 0\n"
" je callfunc # Jump to call funtion if (paramSize == 0)\n"
"# Move params to non-scratch registers\n"
" mov %1,%%rsi # rsi = pArgs\n" // Copy args into rsi
" mov %2,%%r11 # r11 = pFloatArgs (can be NULL)\n" // Copy floatArgs into r11
" mov %3,%%r12d # r12 = paramSize\n" // Copy paramSize into r12
"# Copy arguments from script stack to application stack\n"
"# Order is (first to last):\n"
"# rcx, rdx, r8, r9 & everything else goes on stack\n"
" movq (%%rsi),%%rcx\n"
" movq (%%rsi) +8,%%rdx\n"
" movq (%%rsi) +16,%%r8\n"
" movq (%%rsi) +24,%%r9\n"
"# Negate the 4 params from the size to be copied\n"
" sub $32,%%r12d\n"
" js copyfloat # Jump if negative result\n"
" jz copyfloat # Jump if zero result\n"
"# Now copy all remaining params onto stack allowing space for first four\n"
"# params to be flushed back to the stack if required by the callee.\n"
" add $32,%%rsi # Position input pointer 4 args ahead\n"
" mov %%rsp,%%r13 # Put the stack pointer into r13\n"
" add $32,%%r13 # Leave space for first 4 args on stack\n"
"copyoverflow:\n"
" movq (%%rsi),%%r15 # Read param from source stack into r15\n"
" movq %%r15,(%%r13) # Copy param to real stack\n"
" add $8,%%r13 # Move virtual stack pointer\n"
" add $8,%%rsi # Move source stack pointer\n"
" sub $8,%%r12d # Decrement remaining count\n"
" jnz copyoverflow # Continue if more params\n"
"copyfloat:\n"
"# Any floating point params?\n"
" cmp $0,%%r11\n"
" je callfunc\n"
" movlpd (%%r11),%%xmm0\n"
" movlpd (%%r11) +8,%%xmm1\n"
" movlpd (%%r11) +16,%%xmm2\n"
" movlpd (%%r11) +24,%%xmm3\n"
"callfunc:\n"
"# Call function\n"
" call *%%r14\n"
" movq %%rax,%0\n" // Copy the returned value into the ret variable
: "=r" (ret)
: "r" (args), "r" (floatArgs), "r" (paramSize), "r" (func)
: "r14", "rdi", "rsi", "rsp", "r11", "r12", "rcx", "rdx", "r8", "r9", "r13", "r15"
);

return ret;
}


The changes I did was to use the operands and clobber list. This way I don't need to worry about what the MinGW optimizer will do outside the assembler code. The optimizer may very well decide to move the arguments to a different place.

Now, I'm not sure what the "=r" and "r" strings mean. This is something that still need to study in the gcc manual, but I think it means something like 'regular value'.



[EDIT] Chapter 6 in the article I linked to explains the "r" string. It just means the value will be stored in one of the general purpose registers.