This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]