I. background
In the process of program debugging, a problem occurs. After the program goes into the stack and goes out of the stack, it always runs and uses GDB for debugging. After the stack operation is found, check that the data after the stack is imported does not match when the stack is released.
Ii. Analysis content
1,
Stmfd SP !, {R0-R12, R1}
Previously, it was understood that the first step is to import the stack R1, and then gradually decrease the number of R12 ---> R0. Theoretically, a total of 14 data records are written into the stack.
After decompilation, we found that there was actually one missing and 13 pieces of data were written into the stack.
Decompilation compilation is as follows:
23e062fc: e92d1fffpush {r0, R1, R2, R3, R4, R5, R6, R7, R8, R9, SL, FP, IP}
2,
If you change the preceding two operations
Stmfd SP !, {R1}
Stmfd SP !, {R0-R12}
After decompilation:
23e062fc: e92d0002 push {R1}
23e06300: e92d1fff push {r0, R1, R2, R3, R4, R5, R6, R7, R8, R9, SL, FP, IP}
In this way, there is no problem when the stack goes out.
3,
If so
Stmfd SP !, {LR, R0-R12}
After decompilation:
23e062fc: e92d5fff push {r0, R1, R2, R3, R4, R5, R6, R7, R8, R9, SL, FP, IP, LR}
Iii. Summary
Through this phenomenon, we found that {.....} The registers are arranged in ascending order. If there are repeated registers, they will be ignored directly.
Therefore, you should avoid batch load or store, or load or store in several steps.
Incorrect stm ldm Assembly batch loading command usage