backends: Use PTRACE_GETREGSET for ppc_set_initial_registers_tid
authorMark Wielaard <mark@klomp.org>
Wed, 16 Feb 2022 13:47:46 +0000 (14:47 +0100)
committerMark Wielaard <mark@klomp.org>
Wed, 16 Feb 2022 13:47:46 +0000 (14:47 +0100)
commit52d72316e0d0274b2d717142601c0fff3a77f0ba
treec6e378f2f3fcd8d6b08e97c5630dcb3d9177976d
parentc4726913b7766634cc5d8a97624e1b4708452d73
backends: Use PTRACE_GETREGSET for ppc_set_initial_registers_tid

The code in ppc_initreg.c used PTRACE_PEEKUSER to fetch all registers
one by one. Which is slightly inefficient. It did this because it wanted
things to work on linux 2.6.18 which didn't support PTRACE_GETREGSET.

PTRACE_GETREGSET was only officially since 2.6.34 (but backported
to some earlier versions). It seems ok to require a linux kernel that
supports PTRACE_GETREGSET now. This is much more efficient since it
takes just one ptrace call instead of 44 calls to fetch each register
individually.

For some really old versions we need to include <linux/ptrace.h> to
get PTRACE_GETREGSET defined. And on ppc64 there is no 32bit version
of struct pt_regs available, so we define that ourselves and check
how much data is returned to know whether this is a full pt_regs or
one for a 32bit process. An alternative would be to use the raw
iov_base bytes with 64bit or 32bit offset constants to get at the
registers instead of using a struct with names.

The code works for inspecting a 32bit process from a 64bit build,
but not the other way around (the previous code also didn't). This
could work if we also defined and used a 64bit pt_regs struct on
ppc32. But it seems a use case that is not really used (it was hard
enough finding ppc32 setups to test this on).

Tested against ppc and ppc64 on linux 2.6.32 and glibc 2.12 and
ppc and ppc64 on linux 3.10.0 with glibc 2.17.

Signed-off-by: Mark Wielaard <mark@klomp.org>
backends/ChangeLog
backends/ppc_initreg.c