Unfortunately removing the UNUSED_VAR macros doesn't help.

Are you sure it's not passing the address of the parameter?
It looks correct here:
http://snag.gy/q98dS.jpg

Down the bottom of the image you can see that
[font=courier new,courier,monospace]&args[/font] is [font=courier new,courier,monospace]0xbffff294[/font]
[font=courier new,courier,monospace]&paramSize[/font] is [font=courier new,courier,monospace]0xbffff290 (-4)[/font]
and [font=courier new,courier,monospace]&func[/font] is [font=courier new,courier,monospace]0xbffff28c (-8)[/font]
And [font=courier new,courier,monospace]edx[/font] seems to be set to [font=courier new,courier,monospace]0xbffff294[/font].

Thanks for your help, and no rush, 1.22.1 is still working.
And the mac build of Dustforce isn't out for another 3 weeks

Yes, I'm sure. The paramSize should be at an address 4 bytes higher than args not lower.

You're seeing the addresses of the local variables, and not the arguments. If the local variables had been layed out in the same order as the arguments then it would still have worked, but unfortunately the order was inverted inverted.

Ah, you're right. If I put the function parameters in an array on the stack in the correct order, and pass that array in to the assembly code it works, in debug at least.

I've fixed this problem now in revision 1269. At least the changes I did is working on Linux, but then, it was working before too.

I ended up putting the function arguments in a local array like you did in your test. That is only solution I found that worked for all of the functions. The functions that has fewer arguments could be solved by passing each argument in individual registers, but that would require more changes and would make the code less maintainable.

I'd appreciate it if both Matt and Vasil can confirm that the changes have fixed the problem.

This is what I'm getting if I run just the native calling convention tests:

Same in debug/release apple/gcc compiler

AngelScript version: 2.23.1 WIP
AngelScript options: AS_MAC AS_X86
-- TestExecute passed
--- Assert failed ---
func: void ExecuteString()
mdle: ExecuteString
sect: ExecuteString
line: 1
---------------------
Failed on line 76 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp

TestReturn: cfunction didn't return properly

Failed on line 84 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp
--- Assert failed ---
func: void ExecuteString()
mdle: ExecuteString
sect: ExecuteString
line: 1
---------------------
Failed on line 88 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp
--- Assert failed ---
func: void ExecuteString()
mdle: ExecuteString
sect: ExecuteString
line: 1
---------------------
Failed on line 100 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp
Failed on line 248 in /Users/Matt/Downloads/trunk 2/sdk/tests/test_feature/projects/xcode/../../source/test_cdecl_return.cpp
--------------------------------------------
One of the tests failed, see details above.
[/quote]

I'll see if I can get a better idea of what's going wrong, let me know if there's any other information I can give you.

I don't know if you have any interest in upgrading your mac, and please don't feel obligated to do so.
But I just made a small donation on behalf of Hitbox for your contribution to Dustforce, which might help out if you did want to upgrade.

Thanks,
Matt

At least it seems the changes improved things, which shows that we're moving in the right direction.

That the test_cdecl_return test fails tells me that the returned value in the registers EAX:EDX seems to be getting lost for some reason.

Can you provide a new disassembly of the CallCDeclFunction() function and also the CallSystemFunctionNative() function? I'm pretty sure the EAX:EDX is populated correctly, but they are either overwritten with an incorrect value, or never read from. I'm most inclined to believe it is the latter, caused by the fact that the compiler sees that the CallCDeclFunctionQWord function pointer is really pointing to a function that returns void, and therefore ignores the value in EAX:EDX.

If I'm right, I'll probably have to change the inline assembly to store the value of EAX:EDX in a variable and return that value from the CallCDeclFunction, and all the others too.


Thanks a lot for the donation. It is greatly appreciated.

Though the Mac is a great computer, the one I have is mostly gathering dust. I only have it because I received it as a donation from a previous AngelScript user on Mac. I only bring it up once in a while to do some tests like these for AngelScript. Given that Apple seems to have changed so much in the way XCode/GCC/Clang/LLVM works it seems it won't be much of use for that either nowadays. For that reason I do not feel inclined to spend money on buying a new Mac as the destiny for it will likely be the same.

I feel we've almost uncovered the problem and once this problem is fixed, there probably won't be any further problems until Apple decides to change things again.

Regards,
Andreas

I've made some further changes in revision 1277 that I believe will fix the last problems.

I made the changes based on the suspicion that the return value is ignored due to the functions being declared as returning void.

Please give this new version a try and let me know if any problem remains.

Regards,
Andreas

All of the tests passed with success.[/quote]

Awesome.

Thanks so much for your help with that, and I'm really glad you got it sorted without having to shell out for a new mac.

Great! Thanks for confirming that the fix works.

And thank you for all the help in finding the problem.