diff -Naurp linux-2.6.18-rc6/arch/powerpc/kernel/ptrace.c linux-2.6.18-rc6-mod/arch/powerpc/kernel/ptrace.c
--- linux-2.6.18-rc6/arch/powerpc/kernel/ptrace.c 2006-10-19 18:09:01.000000000 +0530
+++ linux-2.6.18-rc6-mod/arch/powerpc/kernel/ptrace.c 2006-10-19 18:11:37.000000000 +0530
@@ -406,7 +406,7 @@ long arch_ptrace(struct task_struct *chi
case PPC_PTRACE_GETREGS: { /* Get GPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
- unsigned long __user *tmp = (unsigned long __user *)addr;
+ unsigned long __user *tmp = (unsigned long __user *)data;
for (i = 0; i < 32; i++) {
ret = put_user(*reg, tmp);
@@ -421,7 +421,7 @@ long arch_ptrace(struct task_struct *chi
case PPC_PTRACE_SETREGS: { /* Set GPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
- unsigned long __user *tmp = (unsigned long __user *)addr;
+ unsigned long __user *tmp = (unsigned long __user *)data;
for (i = 0; i < 32; i++) {
ret = get_user(*reg, tmp);
@@ -436,7 +436,7 @@ long arch_ptrace(struct task_struct *chi
case PPC_PTRACE_GETFPREGS: { /* Get FPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.fpr)[0];
- unsigned long __user *tmp = (unsigned long __user *)addr;
+ unsigned long __user *tmp = (unsigned long __user *)data;
flush_fp_to_thread(child);
@@ -453,7 +453,7 @@ long arch_ptrace(struct task_struct *chi
case PPC_PTRACE_SETFPREGS: { /* Get FPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.fpr)[0];
- unsigned long __user *tmp = (unsigned long __user *)addr;
+ unsigned long __user *tmp = (unsigned long __user *)data;
flush_fp_to_thread(child);
diff -Naurp linux-2.6.18-rc6/arch/powerpc/kernel/ptrace32.c linux-2.6.18-rc6-mod/arch/powerpc/kernel/ptrace32.c
--- linux-2.6.18-rc6/arch/powerpc/kernel/ptrace32.c 2006-10-19 18:09:01.000000000 +0530
+++ linux-2.6.18-rc6-mod/arch/powerpc/kernel/ptrace32.c 2006-10-19 18:11:41.000000000 +0530
@@ -345,7 +345,7 @@ long compat_sys_ptrace(int request, int
case PPC_PTRACE_GETREGS: { /* Get GPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
- unsigned int __user *tmp = (unsigned int __user *)addr;
+ unsigned int __user *tmp = (unsigned int __user *)data;
for (i = 0; i < 32; i++) {
ret = put_user(*reg, tmp);
@@ -360,7 +360,7 @@ long compat_sys_ptrace(int request, int
case PPC_PTRACE_SETREGS: { /* Set GPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.regs)[0];
- unsigned int __user *tmp = (unsigned int __user *)addr;
+ unsigned int __user *tmp = (unsigned int __user *)data;
for (i = 0; i < 32; i++) {
ret = get_user(*reg, tmp);
@@ -375,7 +375,7 @@ long compat_sys_ptrace(int request, int
case PPC_PTRACE_GETFPREGS: { /* Get FPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.fpr)[0];
- unsigned int __user *tmp = (unsigned int __user *)addr;
+ unsigned int __user *tmp = (unsigned int __user *)data;
flush_fp_to_thread(child);
@@ -392,7 +392,7 @@ long compat_sys_ptrace(int request, int
case PPC_PTRACE_SETFPREGS: { /* Get FPRs 0 - 31. */
int i;
unsigned long *reg = &((unsigned long *)child->thread.fpr)[0];
- unsigned int __user *tmp = (unsigned int __user *)addr;
+ unsigned int __user *tmp = (unsigned int __user *)data;
flush_fp_to_thread(child);
From: supriya kannery <[email protected]>
Date: Wed, 25 Oct 2006 16:23:14 +0530
> If we exchange the last two arguments like,
>
> ptrace (PPC_PTRACE_GETREGS, pid, ®[0], 0);
>
> it works!
Please make sure that programs, such as gdb, aren't using the reversed
argument order. If they are, you cannot "fix" this as it will break
all such applictions.
David Miller wrote:
>From: supriya kannery <[email protected]>
>Date: Wed, 25 Oct 2006 16:23:14 +0530
>
>
>
>>If we exchange the last two arguments like,
>>
>> ptrace (PPC_PTRACE_GETREGS, pid, ®[0], 0);
>>
>>it works!
>>
>>
>
>Please make sure that programs, such as gdb, aren't using the reversed
>argument order. If they are, you cannot "fix" this as it will break
>all such applictions.
>
>
David,
I checked in gdb and ltrace code. None of them are using PPC_PTRACE*
options to get register values.
Man page also doesn't mention these options. Once this is fixed, these
options could be added to man page also.
Irrespective of whether we fix this, documentation of these options in
manpage will clarify its usage I guess.
Thanks, Supriya
From: supriya kannery <[email protected]>
Date: Fri, 27 Oct 2006 12:50:29 +0530
> I checked in gdb and ltrace code. None of them are using PPC_PTRACE*
> options to get register values.
> Man page also doesn't mention these options. Once this is fixed, these
> options could be added to man page also.
>
> Irrespective of whether we fix this, documentation of these options in
> manpage will clarify its usage I guess.
Yep. Are the no current users at all? That's strange...
David Miller wrote:
>From: supriya kannery <[email protected]>
>Date: Fri, 27 Oct 2006 12:50:29 +0530
>
>
>
>> I checked in gdb and ltrace code. None of them are using PPC_PTRACE*
>>options to get register values.
>>Man page also doesn't mention these options. Once this is fixed, these
>>options could be added to man page also.
>>
>>Irrespective of whether we fix this, documentation of these options in
>>manpage will clarify its usage I guess.
>>
>>
>
>Yep. Are the no current users at all? That's strange...
>
>
David,
I guess 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.
We could align these options with the general format of ptrace and then
document in manpage mentioning the relevant kernel version
(like what we have for PTRACE_O_TRACESYSGOOD in which kernel version is
mentioned)
PTRACE_O_TRACESYSGOOD (since Linux 2.4.6)
Thanks, Supriya
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, ®[0]);
>
> the return value is always -1.
>
> If we exchange the last two arguments like,
>
> ptrace (PPC_PTRACE_GETREGS, pid, ®[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
> > 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.
Hi,
> > 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, ®[0]);
> >
> > the return value is always -1.
> >
> > If we exchange the last two arguments like,
> >
> > ptrace (PPC_PTRACE_GETREGS, pid, ®[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