This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: powerpc PTRACE_GETREGS
Hi,
Thanks for your interest in this.
On Mon, 2008-07-28 at 13:42 -0700, Roland McGrath wrote:
> > 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?
I stumbled upon this problem in May, when I was working on powerpc
support for Frysk. I had to change to PTRACE_{PEEK,POKE}USER.
> 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.)
I didn't know/notice PPC_PTRACE_*.
> 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.)
These were the ones I was trying to use.
> 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.
Well, GDB doesn't do any of that fancy stuff, just old PEEKUSER.
That was what made me give up so quickly my effort to use GETREGS.
As this was three months ago, I don't remember exactly what went wrong.
I will create a testcase to verify this. Also I don't rule out that the
problem was some bug in my code...
I'll keep you posted.
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center