Home » Android » arm – Android CPU register names?

arm – Android CPU register names?

Posted by: admin June 15, 2020 Leave a comment

Questions:

This code fragment is extracted from an Android crash report on a Samsung Tab S:

Build fingerprint: 'samsung/chagallwifixx/chagallwifi:5.0.2/LRX22G/T800XXU1BOCC:user/release-keys'
Revision: '7'
ABI: 'arm'
    r0 a0d840bc  r1 a0dcb880  r2 00000001  r3 a0d840bc
    r4 a0dc3c4c  r5 00000000  r6 a066d200  r7 00000000
    r8 32d68f40  r9 a0c359a8  sl 00000014  fp bef3ba84
    ip a0dc3fb8  sp bef3ba10  lr a0c35a0c  pc a0c34bc8  cpsr 400d0010

r0 through r9 are pretty clearly general purpose registers, sp (r13) is the stack pointer, and pc (r15) is the program counter (instruction pointer). Referring to the Wikipedia’s ARM Architecture page Registers section (one of many pages I looked through), I find that lr (r14) is the link register, and cpsr is the “Current Program Status Register.”

I would like to know what sl (r10), fp (r11) and ip (r12) are. I expect ip is not the “instruction pointer” because that function is done by pc (r15).

Is there a reference document I haven’t found that illustrates these names?

How to&Answers:

The current ARM EABI procedure call standard outlines the standard ‘special’ names for r12-r15:

  • PC (r15): Program counter
  • LR (r14): Link register
  • SP (r13): Stack pointer
  • IP (r12): Intra-procedure scratch register*

The GNU tools also still support names from the deprecated legacy APCS as identifiers for the given register numbers, even though they no longer necessarily have any meaning:

  • FP (r11): Frame pointer – may still be true for ARM code; Thumb code tends to keep actual frame pointers in r7, and of course the code may be compiled without frame pointers at all, in which cases “fp” is just another callee-saved general register.
  • SL (r10): Stack limit – I don’t actually know the history of that one, but in most modern code r10 is no more special than r4-r8.

Note that r9 is not necessarily a general-purpose register – the EABI reserves it for platform-specific purposes. Under linux-gnueabi it’s nothing special, but other platforms may use it for special purposes like a TLS or global object table pointer, so it may also go by SB (static base) or TR (thread register).

* The story behind that the limited range of the PC-relative branch instructions – if the linker finds the target of a call ends up more than 32MB away, it may generate a veneer (some extra instructions within range of the call site) as the branch target, that computes the real address and performs an absolute branch, for which it may need a scratch register.