me at kylehuey.com
Mon Nov 24 16:10:58 PST 2014
I have been experimenting with porting rr to ARM Linux. It is
currently capable of recording and replaying simple single threaded
programs that do not make use of async signals (in other words, things
that do not require the performance counters for correct operation).
I am hoping to ascertain whether or not the performance counters are
suitable for our needs in the next couple of weeks.
In the mean time, a brief summary of the various issues that I have encountered:
- PTRACE_SYSEMU is currently only supported on x86. I have a patch
for the kernel for this, and we can simulate this behavior by using
PTRACE_SYSCALL and changing the syscall number to a benign syscall.
- The syscall ABI is different on ARM. In particular the return value
is placed in the register containing the first argument and not the
register containing the syscall number. This means that the syscall
number must be changed in a different manner (PTRACE_SET_SYSCALL) and
that rr code that examines arg1 after syscall execution will fail.
These are pretty easy to deal with.
- The kernel clobbers r when calling PTRACE_GETREGS. It's unclear
if this is going to be a problem in practice. If it is we can patch
the kernel, and roc has suggested a workaround too.
- We cannot correctly set breakpoints at arbitrary addresses on ARM.
Without debugging information you cannot determine whether an address
corresponds to ARM or THUMB instructions, so we can't pick the correct
breakpoint instruction. We may be able to sidestep this by choosing a
4 byte sequence such that the first 2 bytes, second 2 bytes, and the 4
bytes are all interpreted as invalid instructions or breakpoints (I
haven't looked to see if such an opcode exists) or by guessing and
reverting the replay if we guess wrong. We might also be able to
construct sufficient heuristics to avoid this problem in practice.
- This also should be a problem for syscalls, although it appears that
glibc only makes syscalls from ARM code (and not from THUMB).
- There's no hardware support for singlestepping. We have to
disassemble the current instruction and figure out what the next value
of the pc will be, and manually place a breakpoint there.
The code is currently available at https://github.com/khuey/rr/compare/arm.
(h/t cjones for the name 'ArrM')
More information about the rr-dev