Hi,

I am currently migrating an application that uses javascript as a scripting engine, and so far I am pretty happy with angelscript as a replacement :-). There is however an issue on Mac: if dead code stripping is activated for the 32-bit build (64-bit is fine), calling native functions just crash. It is very easy to reproduce: just enable dead code stripping in the XCode test projects and the first function call crashes.

The only thing I could find about this topic is here, and it says that dead code stripping might just strip some assembly instructions used for function calls.

However, when comparing the assembly around the function call in the debugger with and without stripping, there does not seem to be any difference. Also, the crash seems to happen as soon as an system call is made, not before (but maybe it's just the way the stack is screwed).

Do you have any idea of how this could be fixed? Maybe there is a way to tell the linked not to strip the inline asm sections, but I have not found it yet...

Thanks again for creating this great scripting engine!

Please find attached a screenshot of the stack when calling a simple print function registered with angelscript and called as shown below. It crashes when creating the string object (first native function call).

print("HELLO");

I'll need to look into this, but I guess there is some property needed on the inline assembly to tell the compiler not to remove it when using dead_code_stripping.

For now it's best not to use this option when compiling as_callfunc_x86.cpp.

Thanks! The issue is that this option is not used at compile but link time. So it's when linking with the angelscript library that it gets stripped out. There is indeed probably an option for inline assembly not to get stripped, but I am no asm expert, unfortunately and I have not been able to find it in the docs (yet).

Since this occurs at link time, this is quite annoying: it means you cannot use DEAD_CODE_STRIPPING at all when building software if using angelscript as a static lib. And when you link with large frameworks, it can make a big difference in both size and performance. :-(