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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
