Re: [PATCH] 2-ptrace_multi
From: Renzo Davoli
Date: Mon May 22 2006 - 11:05:02 EST
On Mon, May 22, 2006 at 09:02:22AM -0400, Daniel Jacobowitz wrote:
> On Sun, May 21, 2006 at 05:28:10PM +0200, Renzo Davoli wrote:
> > It is not enough. I am fixing the [GS]ETREGS for ppc32 but it happens
> > that the error number is stored in the register PT_CCR (a.k.a. R38)
> > so I need an extra call to get that, then I need the program counter which is
> > in PT_NIP (R31). [GS]ETREGS for ppc load/store just the range R0-R31.
> > so I need 3 syscalls for each syscall issued by the ptraced process
> > instead of just one.
> Then have you considered changing the regset returned to be actually
> useful? Especially for ppc32 where you say it was not previously
Then it would be inconsistent with ppc64 where it does exist, and ppc64
has the very same problem.
So the solution would be to patch also the ppc64 [GS]ETREGS breaking
compatibility with existing applications.
The MULTI proposal was a way to have a fast, simple, safe support.
Fast: one syscall does all
simple: it is a vector of calls with the params of std ptrace calls
safe: if is not a new call, the security checks for ptrace are already
flexible: with [GS]ETREGS you can get only the registers you need
instead of all the registers (this is just an example).
PPC wants to read/write 32 registers, i386 17, x86_64 21 etc,
when maybe just some of the registers are meaningful to your
application. Using [GS]ETREGS, you have to save the entire register set
somewhere to restore them after some changes. This applies also to areas
of memory, and other ptrace commands.
backward compatible: if you did not use it, nothing changes in ptrace
If you do not find this proposal interesting, I'll continue to support
it as a specific patch for umview. I am not here to "sell" any solution.
On the contrary I think it might be useful in many applications.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/