Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS

On Wed, 2006-10-25 at 16:23 +0530, supriya kannery wrote:

In ptrace, when request is PPC_PTRACE_GETREGS, SETREGS, GETFPREGS and 
SETFPREGS, order of the last two arguments is not correct.

General format of ptrace is ptrace (request, pid, addr, data).  For the 
above mentioned request ids in ppc64, if we use ptrace like

 long reg[32];
 ptrace (PPC_PTRACE_GETREGS, pid, 0, &reg[0]);

the return value is always -1.

If we exchange the last two arguments like,

 ptrace (PPC_PTRACE_GETREGS, pid, &reg[0], 0);

it works!

This is because PPC_PTRACE_GETREGS option for powerpc is implemented 
such that general purpose
registers of the child process get copied to the address variable 
instead of data variable. Same is
the case with other PPC request options PPC_PTRACE_SETREGS, GETFPREGS 
and SETFPREGS.

Prepared a patch for this problem and tested with 2.6.18-rc6 kernel. 
This patch can be applied directly to 2.6.19-rc3 kernel.

A more appropriate place to send this would be the linux-ppc development
list.

-- 
dwmw2

On Wed, 2006-11-22 at 18:36 +0000, David Woodhouse wrote:

On

quoted

This is because PPC_PTRACE_GETREGS option for powerpc is implemented 
such that general purpose
registers of the child process get copied to the address variable 
instead of data variable. Same is
the case with other PPC request options PPC_PTRACE_SETREGS, GETFPREGS 
and SETFPREGS.

Prepared a patch for this problem and tested with 2.6.18-rc6 kernel. 
This patch can be applied directly to 2.6.19-rc3 kernel.

A more appropriate place to send this would be the linux-ppc development
list.

Also it's possible that existing code like gcc relies on that "feature"
no ?

Ben.
 

Benjamin Herrenschmidt wrote:

On Wed, 2006-11-22 at 18:36 +0000, David Woodhouse wrote:
 

quoted

On
   

quoted

This is because PPC_PTRACE_GETREGS option for powerpc is implemented
such that general purpose
registers of the child process get copied to the address variable
instead of data variable. Same is
the case with other PPC request options PPC_PTRACE_SETREGS, GETFPREGS
and SETFPREGS.

Prepared a patch for this problem and tested with 2.6.18-rc6 kernel.
This patch can be applied directly to 2.6.19-rc3 kernel.
     

A more appropriate place to send this would be the linux-ppc development
list.
   

Also it's possible that existing code like gcc relies on that "feature"
no ?

Ben.


 

Thanks David for posting this in ppc-dev list.
   I checked in GDB and ltrace which uses ptrace(). None of them are using PPC_PTRACE* options to get register values. The reasons for its less (or no) usage could be
1. These options are not documented in manpage
2. The usage is different from the general format of ptrace
3. These are used for copying all the registers. Most applications will require data from a single addr/register at a time and can get this data from a specific register/address using PEEKTEXT or POKETEXT options.
Supriya

Hi,

quoted

In ptrace, when request is PPC_PTRACE_GETREGS, SETREGS, GETFPREGS and 
SETFPREGS, order of the last two arguments is not correct.

General format of ptrace is ptrace (request, pid, addr, data).  For the 
above mentioned request ids in ppc64, if we use ptrace like

 long reg[32];
 ptrace (PPC_PTRACE_GETREGS, pid, 0, &reg[0]);

the return value is always -1.

If we exchange the last two arguments like,

 ptrace (PPC_PTRACE_GETREGS, pid, &reg[0], 0);

it works!

This is because PPC_PTRACE_GETREGS option for powerpc is implemented 
such that general purpose
registers of the child process get copied to the address variable 
instead of data variable. Same is
the case with other PPC request options PPC_PTRACE_SETREGS, GETFPREGS 
and SETFPREGS.

Prepared a patch for this problem and tested with 2.6.18-rc6 kernel. 
This patch can be applied directly to 2.6.19-rc3 kernel.

I looked at this a while ago and my decision at the time was to keep the
old implementation around for a while and create two new ones that match
the x86 numbering:

#define PTRACE_GETREGS            12
#define PTRACE_SETREGS            13
#define PTRACE_GETFPREGS          14
#define PTRACE_SETFPREGS          15

I hate gratuitous differences, each ptrace app ends up with a sea of
ifdefs.

Also I think it would be worth changing getregs/setregs to grab the
entire pt_regs structure. Otherwise most ops (gdb, strace etc) will just
have to make multiple ptrace calls to get the nia etc.

Anton

Anton Blanchard writes:

I looked at this a while ago and my decision at the time was to keep the
old implementation around for a while and create two new ones that match
the x86 numbering:

#define PTRACE_GETREGS            12
#define PTRACE_SETREGS            13
#define PTRACE_GETFPREGS          14
#define PTRACE_SETFPREGS          15

I hate gratuitous differences, each ptrace app ends up with a sea of
ifdefs.

Also I think it would be worth changing getregs/setregs to grab the
entire pt_regs structure. Otherwise most ops (gdb, strace etc) will just
have to make multiple ptrace calls to get the nia etc.

Did you do a patch to do that?

Paul.