Menu
I've recently encountered a strange behaviour of ARM Cortex-A8 when programming it in Assembly. Whenever I MOV anything into R4, my program crashes (stack dump below)
10-14 09:48:43.117: INFO/DEBUG(3048): Build fingerprint: 'google/soju/crespo:2.3.6/GRK39F/189904:user/release-keys'
10-14 09:48:43.121: INFO/DEBUG(3048): pid: 7082, tid: 7082 >>> neontests <<<
10-14 09:48:43.121: INFO/DEBUG(3048): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000001
10-14 09:48:43.125: INFO/DEBUG(3048): r0 00000001 r1 afa025b6 r2 00000000 r3 bec77051
10-14 09:48:43.128: INFO/DEBUG(3048): r4 00000001 r5 bec7704c r6 00000001 r7 00000004
10-14 09:48:43.128: INFO/DEBUG(3048): r8 00000005 r9 00000000 10 4214cca4 fp 800a5368
10-14 09:48:43.128: INFO/DEBUG(3048): ip afa03110 sp bec77010 lr afa0133b pc afd37b42 cpsr 60000030
10-14 09:48:43.132: INFO/DEBUG(3048): d0 0000000200000053 d1 0000000400000074
10-14 09:48:43.132: INFO/DEBUG(3048): d2 000000060000006f d3 0000000800000070
10-14 09:48:43.132: INFO/DEBUG(3048): d4 006f0065006e002e d5 007300650074006e
10-14 09:48:43.136: INFO/DEBUG(3048): d6 0000000c00000005 d7 0000002000000015
10-14 09:48:43.136: INFO/DEBUG(3048): d8 0000000c00000005 d9 0000002000000015
10-14 09:48:43.140: INFO/DEBUG(3048): d10 0000000000000000 d11 0000000000000000
10-14 09:48:43.140: INFO/DEBUG(3048): d12 0000000000000000 d13 0000000000000000
10-14 09:48:43.140: INFO/DEBUG(3048): d14 0000000000000000 d15 0000000000000000
10-14 09:48:43.144: INFO/DEBUG(3048): d16 800220e8401644a8 d17 bff0000000000000
10-14 09:48:43.144: INFO/DEBUG(3048): d18 3ff0000000000000 d19 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d20 0000000000000000 d21 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d22 3ff0000000000000 d23 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d24 3ff0000000000000 d25 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d26 0000000000000000 d27 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d28 0000000000000000 d29 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): d30 0000000000000000 d31 0000000000000000
10-14 09:48:43.148: INFO/DEBUG(3048): scr 20000012
10-14 09:48:43.195: INFO/DEBUG(3048): #00 pc 00037b42 /system/lib/libc.so
10-14 09:48:43.195: INFO/DEBUG(3048): #01 pc 00001338 /system/lib/liblog.so
10-14 09:48:43.199: INFO/DEBUG(3048): #02 pc 00001482 /system/lib/liblog.so
10-14 09:48:43.199: INFO/DEBUG(3048): #03 pc 00000c54 /data/data/neontests/lib/libneon_tests.so
10-14 09:48:43.199: INFO/DEBUG(3048): #04 pc 00017e34 /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #05 pc 0004968c /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #06 pc 0004ee62 /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #07 pc 0001d034 /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #08 pc 000220e4 /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #09 pc 00020fdc /system/lib/libdvm.so
10-14 09:48:43.199: INFO/DEBUG(3048): #10 pc 0005fdde /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #11 pc 00067b52 /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #12 pc 0001d034 /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #13 pc 000220e4 /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #14 pc 00020fdc /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #15 pc 0005fc40 /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #16 pc 0004c126 /system/lib/libdvm.so
10-14 09:48:43.203: INFO/DEBUG(3048): #17 pc 00032572 /system/lib/libandroid_runtime.so
10-14 09:48:43.203: INFO/DEBUG(3048): #18 pc 0003341e /system/lib/libandroid_runtime.so
10-14 09:48:43.203: INFO/DEBUG(3048): #19 pc 00008cca /system/bin/app_process
10-14 09:48:43.207: INFO/DEBUG(3048): #20 pc 00014b52 /system/lib/libc.so
10-14 09:48:43.207: INFO/DEBUG(3048): code around pc:
10-14 09:48:43.207: INFO/DEBUG(3048): afd37b20 18801889 c003f810 c003f801 d2f93b01
10-14 09:48:43.207: INFO/DEBUG(3048): afd37b30 bf00bdf0 2200b510 3201e003 4618b90b
10-14 09:48:43.207: INFO/DEBUG(3048): afd37b40 5c83e004 42a35c8c 1b18d0f7 bf00bd10
10-14 09:48:43.207: INFO/DEBUG(3048): afd37b50 b152b530 5cc42300 42ac5ccd 1b60d001
10-14 09:48:43.207: INFO/DEBUG(3048): afd37b60 b114e004 429a3301 2000d1f5 bf00bd30
10-14 09:48:43.207: INFO/DEBUG(3048): code around lr:
10-14 09:48:43.207: INFO/DEBUG(3048): afa01318 fffffff4 00001e20 b088b570 4615460c
10-14 09:48:43.207: INFO/DEBUG(3048): afa01328 b9099001 447c4c28 46204928 f7ff4479
10-14 09:48:43.207: INFO/DEBUG(3048): afa01338 2800edc4 4926d02e 22034620 f7ff4479
10-14 09:48:43.207: INFO/DEBUG(3048): afa01348 b338edc2 46204923 f7ff4479 b308edb6
10-14 09:48:43.207: INFO/DEBUG(3048): afa01358 46204921 f7ff4479 b1d8edb0 4620491f
10-14 09:48:43.207: INFO/DEBUG(3048): stack:
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fd0 800a5368
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fd4 afd1c701 /system/lib/libc.so
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fd8 bec771f0
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fdc bec77051
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fe0 0000ce60
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fe4 000003fa
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fe8 ffff0208
10-14 09:48:43.207: INFO/DEBUG(3048): bec76fec bec7704c
10-14 09:48:43.207: INFO/DEBUG(3048): bec76ff0 000003ff
10-14 09:48:43.207: INFO/DEBUG(3048): bec76ff4 00000000
10-14 09:48:43.210: INFO/DEBUG(3048): bec76ff8 00000003
10-14 09:48:43.210: INFO/DEBUG(3048): bec76ffc 00000004
10-14 09:48:43.210: INFO/DEBUG(3048): bec77000 80400d90 /data/data/neontests/lib/libneon_tests.so
10-14 09:48:43.210: INFO/DEBUG(3048): bec77004 bec7704c
10-14 09:48:43.210: INFO/DEBUG(3048): bec77008 df002777
10-14 09:48:43.210: INFO/DEBUG(3048): bec7700c e3a070ad
10-14 09:48:43.210: INFO/DEBUG(3048): #00 bec77010 00000001
10-14 09:48:43.210: INFO/DEBUG(3048): bec77014 afa0133b /system/lib/liblog.so
10-14 09:48:43.210: INFO/DEBUG(3048): #01 bec77018 80400420 /data/data/neontests/lib/libneon_tests.so
10-14 09:48:43.210: INFO/DEBUG(3048): bec7701c 00000004
10-14 09:48:43.210: INFO/DEBUG(3048): bec77020 bec7701c
10-14 09:48:43.210: INFO/DEBUG(3048): bec77024 00000001
10-14 09:48:43.210: INFO/DEBUG(3048): bec77028 80400d90 /data/data/neontests/lib/libneon_tests.so
10-14 09:48:43.210: INFO/DEBUG(3048): bec7702c 00000014
10-14 09:48:43.210: INFO/DEBUG(3048): bec77030 00000000
10-14 09:48:43.210: INFO/DEBUG(3048): bec77034 00000000
10-14 09:48:43.210: INFO/DEBUG(3048): bec77038 bec7704c
10-14 09:48:43.210: INFO/DEBUG(3048): bec7703c afd4d5c8
10-14 09:48:43.210: INFO/DEBUG(3048): bec77040 00000001
10-14 09:48:43.210: INFO/DEBUG(3048): bec77044 afa01487 /system/lib/liblog.so
Edit: Stack dump above is the result of the following code (apologies, GNU Assembly highlighting seems to be a bit odd here):
.arm
.global asm_test
asm_test:
mov r0, #4 @make sure r0 is not the same as r4
mov r4, #1 @move to r4 something different from r0
mov pc, lr @return from function
I'm calling it from (native) C as follows:
#include <jni.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <arm_neon.h>
#include <android/log.h>
#include "com_something_neontests_NativeLib.h"
extern volatile int asm_test(void);
JNIEXPORT jint JNICALL Java_com_something_neontests_NativeLib_asmTry
(JNIEnv * env, jobject obj)
{
__android_log_print(ANDROID_LOG_INFO, "com.something.neontests", "Start!");
asm_test();
__android_log_print(ANDROID_LOG_INFO, "com.something.neontests", "Done!");
return 0;
}
Here are a few things I notice. First, whenever I assign anything to R4, be it MOV R4, #2 or ADD R4, R0, R1, the result does end up in R4 before the program crashes, but the same result also always ends up in R0. I also found out that I can POP stuff from the stack into R4. No other registers exhibit this same behaviour. Assembly code compiles using Android NDK, which I believe uses GCC 4.4.3. I tested it on several Android phones and everything seems to be consistent.
I know that all registers are sectioned such that R0-R3 take in arguments, R4-R12 are variable registers, then there are special registers and so on. Perhaps this behaviour is caused by some sort of C calling convention I've never heard about? Is there an explanation for this, is it expected?
Cheers! = )
Update:
As @Graham kindly pointed out, r4 (alternatively v1) is a variable register which should be preserved. However, in the link provided in his answer, ARM documentation itself makes use of the v1 register, by first saving its result on the stack along with value of another preserved register:
STMDB sp!,{v1,lr}
LDR v1,[a2,#0]
and later retrieving their values. When I compile this code, it crashes the same way as my original, but
STMDB sp!,{v1,lr}
LDR v2,[a2,#0]
doesn't (notice v2 instead of v1).
974
What we are trying to explain is that you need to do this if you want to use r4 in a function:
.globl asm_test
asm_test:
stmdb r13!,{r4}
mov r0, #4 @make sure r0 is not the same as r4
mov r4, #1 @move to r4 something different from r0
ldmia r13!,{r4}
mov pc, lr @return from function
Otherwise you leave a time bomb that goes off at some point down the road. The compiler has allocated r4 for something in a higher level function, and by the rules nobody can change that register so that higher level call does not have to protect r4, by messing it up at the right time and place you create the problem, how the problem behaves is code dependent. And will explain why other registers, in this case, are not sensitive. Sometimes when you do this you wont actually crash, sometimes perhaps a string is printed wrong or a loop repeats itself or exits early.
To see what is going on please disassemble the function in question (not the source code but a disassembly). plus the functions that called it and the functions that called that until r4 shows up in one of those surrounding functions. examine what r4 is being used for.
You can also change the behavior if your asm_test() calling function were to have local variables that are used before and after the asm_test() call in such a way that the optimizer keeps them in registers, but also such that the optimizer does not remove the code all together:
void fun ( void )
{
int r;
r=10;
asm_test();
r++;
}
The optimizer would completely remove r in the above code, but:
int fun ( int a, int b, int c, int d )
{
int e;
e=a+b+c+d;
b=asm_test(a+d);
e+=b;
return(e);
}
creates more than enough to force the compiler to build a stack frame.
00000000 <fun>:
0: e0811000 add r1, r1, r0
4: e92d4010 push {r4, lr}
8: e0830000 add r0, r3, r0
c: e0814002 add r4, r1, r2
10: e0844003 add r4, r4, r3
14: ebfffffe bl 0 <asm_test>
18: e0840000 add r0, r4, r0
1c: e8bd8010 pop {r4, pc}
r4 is the variable e in this case (around the asm_test call) and by messing up r4 you will change what the function fun() returns. If that value were never used on the call to fun for example your modification of r4 would go unnoticed.
The compilers follow the calling convention rules and expect all callees to as well, if you mess with that the ways that it can crash/fail go from no effect to quite serious, so you need to conform to those calling conventions in your asm.
169
According to APCS, R4 is one of the registers which you must preserve. If you need to use it, then store it on the stack on entry, and pop it off again on exit. There are some registers, such as R0-R3, which are scratch registers; you are allowed to corrupt these inside your routine without preserving them.
See the docs for a description of which registers you must preserve and restore before returning from your routine.
v1-v8, [f4-f7]
These are used as register variables. They must be preserved by called functions.
v1 is the APCS alternative name for R4.
7
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
