I have an NDK app out on market and got a native crash report about a SIGILL
signal. (I use google breakpad to generate native crash reports.) Here are the details:
armeabi-v7a
, with NEON support.0x399cc
, the signal was SIGILL
, and it's in my code.Registers and disassembly:
r4 = 0x001d50f0 r5 = 0x001d50f0 r6 = 0x598e2a3c r7 = 0x00000000
r8 = 0x00000001 r9 = 0x001c22b0 r10 = 0x00000000 fp = 0x81216264
sp = 0x598e2a18 lr = 0x816399cb pc = 0x816399cc
0x000399c6 <_ZN8Analyzer15setExpAvgFactorEi+22>: blx 0x30508
0x000399ca <_ZN8Analyzer15setExpAvgFactorEi+26>: fconstd d16, #7
0x000399ce <_ZN8Analyzer15setExpAvgFactorEi+30>: vldr d17, [pc, #32] ; 0x399f2 <_ZN8Analyzer15setExpAvgFactorEi+66>
Full source and assembler available here (it's short, basically 2 lines of C++.)
You can see that 0x399cc
is in the middle of the fconstd
instruction. According to arm.com this instruction was added in VFP-v3
, which should (I think) be available in any modern processor.
What could be going on? Does the fact that the address is in the middle of an instruction point to a corrupt pointer somewhere? (Note that the backtrace makes perfect sense, so it's not like this function was somehow called on accident.) Or is it something else?
Ok, I got it: the NVIDIA Tegra 2 only has 16 64-bit GPU registers, and therefore to target it you must compile using -mfpu=vfpv3-d16
. The instruction in question uses register d16
, which is "just too many". :(
Here is a reference to an NVIDIA forum where an employee mentions this limitation: http://developer.nvidia.com/tegra/forum/optimal-performance-guidelines
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With