Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Processors/DSPs
?
?
Processors/DSPs??

ARM64 vs ARM32: A guide for Linux programmers

Posted: 06 Nov 2015 ?? ?Print Version ?Bookmark and Share

Keywords:ARM? Linux programmers? just-in-time? RISC? cryptographic?

The solution is to use PTRACE_GETREGSET and PTRACE_SETREGSET with various different arguments to read these registers.

Here is a table of the GETREGS-style request and the closest equivalent GETREGSET request. Different REGSETs are acquired through different arguments to addr ptrace() argument.

Note that NT_ARM_HW_BREAK and NT_ARM_HW_WATCH behave identically in a GETREGSET request.

Using GETREGSET is not as simple as using GETREGS, though. For a GETREGS request like this:

ptrace(PTRACE_GETREGS, 0, 0, regs);

GETREGSET would look like this:

struct
{
???void* buf;
???size_t len;
} my_iovec = { regs, sizeof(*regs)};

ptrace(PTRACE_GETREGSET, 0, (void*) NT_PRSTATUS, &my_iovec);

Note, too, that I have said "the closest equivalent GETREGSET request." Naturally, the AArch64 register set is different from the ARM 32-bit one, but there are more differences between the two beyond the register set.

Figure 1 shows a diagram of the registers returned from an ARM 32-bit GETREGS and AArch64 GETREGSET instruction.

Table: ARM 32-bit and closest equivalent AArch64 ptrace requests.

Figure 1: GETREGS and GETREGSET.

Those familiar with AArch64 may notice that with GETREGSET we've been given a "cpsr" register, yet the hardware architecture does not have one. What's returned with GETREGSET has been synthesised into a cpsr-like layout from the individually accessible fields on AArch64.

A more notable difference between the two is the lack of orig_r0 (or orig_x0) for GETREGSET. This lack has to do with syscalls. On ARM 32-bit, a syscall number gets placed in r7 and the syscall arguments are placed in the argument registers r0-r3 prior to a syscall(SVC) instruction. The value returned from the syscall is located in r0 (as per the usual APCS, r7 in exceptional circumstances). After the kernel returns from the syscall, orig_r0 provides the original first argument to the syscall (which had been overwritten by the return value).

I actually don't know what use a "normal" application is supposed to make of this original first argument. We use it for our support of restart_syscall, where the return value is ERESTART_RESTARTBLOCK.

Unfortunately the lack of orig_x0 is a problem for us that we have yet to resolve in all circumstances. If we have recorded the entry to the syscall, then we have all the information we need. However, if we have attached during a restart_syscall, then we do not know the original value of x0. Our only option is to allow the kernel to restart the syscall, but this restart is inefficient for us as we can't optimise the recording of the syscall.

Returning to the subject of GETREGS versus GETREGSET: GETHBPREGS and NT_ARM_HW_BREAK are also significantly different. For a GETHBPREGS request, you use the addr field in the ptrace call to request a particular hardware breakpoint register. NT_ARM_HW_BREAK returns all hardware breakpoint registers.

The best place to look for more information on these ptrace differences is to examine the AArch64 ptrace source file: arch/arm64/kernel/ptrace.c

Increased use of locks
Load/store exclusives are the instructions used in ARM 32- and 64-bit to support atomic accesses.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page



Article Comments - ARM64 vs ARM32: A guide for Linux pr...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top