This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
powerpc PTRACE_GETREGS
[I hate long conflated threads with useless subject lines.]
> One thing that is specific to powerpc that I'd like to have fixed is
> PTRACE_GETREGS and PTRACE_SETREGS. They're currently buggy, so GDB on
> Power uses PTRACE_PEEKUSR and PTRACE_POKEUSR which is slower.
Are you sure this information is up to date?
There are two different sets of ptrace requests for this on powerpc.
PPC_PTRACE_[GS]ETREGS and PPC_PTRACE_[GS]ETFPREGS are the old ones.
Those have been around in old kernels for a while. They include
r0..r31 and nothing else. (These also invert the ptrace argument
order from what x86 uses.)
In more recent kernels, there are also PTRACE_[GS]ETREGS,
PTRACE_[GS]ETFPREGS, and PTRACE_[GS]ETREGS64. These use the standard
argument order, and they access the whole 'struct pt_regs' (asm/ptrace.h).
(There are also [GS]ETVRREGS, [GS]ETEVRREGS, [GS]ETVSRREGS now.)
I'm not aware off hand of there having been kernel bugs with any of
these. There are just their different idiosyncratic interfaces.
Also, I think with the old PPC_* set, 32-bit kernels didn't support
some of these that 64-bit kernels supported for 32-bit processes.
AFAIK you should do fine using PTRACE_GETREGS when it's there, fall
back to PPC_PTRACE_GETREGS + fill in with PEEKUSR, and ultimately
fall back to just using PEEKUSR if neither is there.
Thanks,
Roland