* Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
@ 2006-10-25 10:53 supriya kannery
2006-10-25 20:43 ` David Miller
2006-11-22 18:36 ` David Woodhouse
0 siblings, 2 replies; 9+ messages in thread
From: supriya kannery @ 2006-10-25 10:53 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
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.
[-- Attachment #2: ppc_ptrace_params.patch --]
[-- Type: text/plain, Size: 3448 bytes --]
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);
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-10-25 10:53 Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS supriya kannery
@ 2006-10-25 20:43 ` David Miller
2006-10-27 7:20 ` supriya kannery
2006-11-22 18:36 ` David Woodhouse
1 sibling, 1 reply; 9+ messages in thread
From: David Miller @ 2006-10-25 20:43 UTC (permalink / raw)
To: supriyak; +Cc: linux-kernel
From: supriya kannery <supriyak@in.ibm.com>
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-10-25 20:43 ` David Miller
@ 2006-10-27 7:20 ` supriya kannery
2006-10-27 7:10 ` David Miller
0 siblings, 1 reply; 9+ messages in thread
From: supriya kannery @ 2006-10-27 7:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel
David Miller wrote:
>From: supriya kannery <supriyak@in.ibm.com>
>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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-10-27 7:20 ` supriya kannery
@ 2006-10-27 7:10 ` David Miller
2006-10-31 12:18 ` supriya kannery
0 siblings, 1 reply; 9+ messages in thread
From: David Miller @ 2006-10-27 7:10 UTC (permalink / raw)
To: supriyak; +Cc: linux-kernel
From: supriya kannery <supriyak@in.ibm.com>
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...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-10-27 7:10 ` David Miller
@ 2006-10-31 12:18 ` supriya kannery
0 siblings, 0 replies; 9+ messages in thread
From: supriya kannery @ 2006-10-31 12:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel
David Miller wrote:
>From: supriya kannery <supriyak@in.ibm.com>
>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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-10-25 10:53 Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS supriya kannery
2006-10-25 20:43 ` David Miller
@ 2006-11-22 18:36 ` David Woodhouse
2006-11-22 21:35 ` Benjamin Herrenschmidt
2006-12-04 21:58 ` Anton Blanchard
1 sibling, 2 replies; 9+ messages in thread
From: David Woodhouse @ 2006-11-22 18:36 UTC (permalink / raw)
To: supriya kannery; +Cc: linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
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
[-- Attachment #2: ppc_ptrace_params.patch --]
[-- Type: text/x-patch, Size: 3448 bytes --]
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);
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-11-22 18:36 ` David Woodhouse
@ 2006-11-22 21:35 ` Benjamin Herrenschmidt
2006-12-04 21:58 ` Anton Blanchard
1 sibling, 0 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2006-11-22 21:35 UTC (permalink / raw)
To: David Woodhouse; +Cc: supriya kannery, linuxppc-dev, linux-kernel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-11-22 18:36 ` David Woodhouse
2006-11-22 21:35 ` Benjamin Herrenschmidt
@ 2006-12-04 21:58 ` Anton Blanchard
2007-04-30 5:42 ` Paul Mackerras
1 sibling, 1 reply; 9+ messages in thread
From: Anton Blanchard @ 2006-12-04 21:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: supriya kannery, linuxppc-dev, linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS
2006-12-04 21:58 ` Anton Blanchard
@ 2007-04-30 5:42 ` Paul Mackerras
0 siblings, 0 replies; 9+ messages in thread
From: Paul Mackerras @ 2007-04-30 5:42 UTC (permalink / raw)
To: Anton Blanchard; +Cc: David Woodhouse, linuxppc-dev, linux-kernel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-04-30 5:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-25 10:53 Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS supriya kannery
2006-10-25 20:43 ` David Miller
2006-10-27 7:20 ` supriya kannery
2006-10-27 7:10 ` David Miller
2006-10-31 12:18 ` supriya kannery
2006-11-22 18:36 ` David Woodhouse
2006-11-22 21:35 ` Benjamin Herrenschmidt
2006-12-04 21:58 ` Anton Blanchard
2007-04-30 5:42 ` Paul Mackerras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox