Allright, just notice that in 2.23.0 I did not use native conventions on android! Its the first time now and I never saw it work at all, so nothing to compare to! If you meant for the other bug, then its allright :D

Oh, ok. Then it is going to be difficult.

I'll see if I can find the time to install the Android development kit and play around witth this, hopefully there shouldn't be a lot of changes needed, but a lot of tests needs to be made to determine what's wrong. Especially since debugging seems to be so difficult. This will take time, so you'll need to continue with the generic calling conventions for now.

The problem is reproducible in the emulator in the Android development kit as well, right?

I don't know that as I always use real devices for testing, but the emulator is a true ARM emulator so it is supposed to be "EXACTLY" like a real device..

I will stick to the generics, yes. I would like to give you further help and I will if you need, but I am not sure what to do anymore as I dont have any fair logic of assembly and native conventions..

I've been trying to debug the crashes with ndk-stack but nothing is reported to me.. its weird..hard to debug..

Can you do a disassembly of that void testP() function you tested with? Or rather, compile the function to assembler code (compiler switch -s, I believe).

At least I should be able to see if the assembler code is how AngelScript expects it to be.

wow, this is the craziest thing I've read about templates in a while.

Also, have you overloaded the << operator so that you can use it with ofstreams? that's quite handy :D I'll have to do that sometime.

could you post all of the compiler and linker setting you're using? I'm a little curious as to why this is happening, and I have my summer vacations in around ten days. I'll try and reproduce this on MSVC 2010.

Thanks

What do you mean with the << operator? Didn't get the context :o

The settings I can post them later, windows and android even :)

@Andreas

I created a.cpp , containing only testP(){} and compiled it the same way my engine's library is being compiled, outputting to assembly. Here's the result a.s

.arch armv5te
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.file "a.cpp"
.text
.align 2
.global _Z5testPv
.type _Z5testPv, %function
_Z5testPv:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
bx lr
.size _Z5testPv, .-_Z5testPv
.ident "GCC: (GNU) 4.6 20120106 (prerelease)"
.section .note.GNU-stack,"",%progbits
 

arm-linux-androideabi-g++.exe -S -c a.cpp -Wno-psabi -O0 -marm -fno-strict-aliasing -funswitch-loops -finline-limit=100 -fomit-frame-pointer -fno-exceptions -fpic -fstack-protector -frtti -fno-short-enums
 

The assembly instruction appears to be as expected.

The function is called from as_callfunc_arm_gcc.S with an instruction 'blx r4', so the correct way to return to the caller is with a call to 'bx lr'.

I suspect the crash is likely happening even before the call to the registered function. Probably somewhere in as_callfunc_arm_gcc.cpp.

Would you mind adding a few cout's in the as_callfunc_arm.gcc.cpp code to see how far it gets before it crashes? And to see which path it takes in the conditions?

About the ARM now, here is the compilation command of one source file from angelscript, compiling the ARM version for the NDK.

"Compile++ thumb : angelscript <= as_scriptengine.cpp
...-mthumb...

LOCAL_ARM_MODE := arm

@quarnster: I added that line to the makefile and it compiled the arm library fine, i tested it and it worked. funny.. :) Thanks.

Because im curious, and to make sure that line was the actual fixer, i took it off again and recompiled but i got the same working result.. Could it change the default compiler settings somehow or what?

This topic's issues are nice, very nice. :)