[PATCH] Use PTRACE_GETREGS on i386

[Dmitry V. Levin]

On Fri, Aug 26, 2011 at 11:50:15AM +0200, Denys Vlasenko wrote:
> On Thu, 2011-08-25 at 21:10 +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 25, 2011 at 12:10:06PM +0200, Denys Vlasenko wrote:
> > > While discussing ptrace speedup, in one email Linus said
> > > that it's stupid that strace doesn't even use already existing
> > > speedups, such as PTRACE_GETREGS.
> > 
> > Yes, use of PTRACE_GETREGS is a long awaited change.
> > I expect a significant reduction of ptrace() syscall invocations.
> > 
> > > I guess we need to add a check on startup to make sure PTRACE_GETREGS works?
> > 
> > PTRACE_GETREGS is quite ancient thing, it is supported even by linux-2.2.26,
> > so I see no need in the runtime check this time.
> > 
> > > --- strace.5/syscall.c	2011-08-25 10:39:36.000000000 +0200
> > > +++ strace.6/syscall.c	2011-08-25 11:51:32.148543603 +0200
> > > @@ -716,7 +716,28 @@ struct tcb *tcp_last = NULL;
> > >  
> > >  #ifdef LINUX
> > >  # if defined (I386)
> > > -static long eax;
> > > +struct i386_user_regs_struct {
> > > +	long ebx;
> > > +	long ecx;
> > > +	long edx;
> > > +	long esi;
> > > +	long edi;
> > > +	long ebp;
> > > +	long eax;
> > > +	long xds;
> > > +	long xes;
> > > +	long xfs;
> > > +	long xgs;
> > > +	long orig_eax;
> > > +	long eip;
> > > +	long xcs;
> > > +	long eflags;
> > > +	long esp;
> > > +	long xss;
> > > +	/* Just in case we forgot a few fields and kernel would write more... */
> > > +	long paranoia[8];
> > > +};
> > > +static struct i386_user_regs_struct i386_regs;
> > 
> > I suppose we shouldn't hurry with this.  There is a <asm/ptrace.h> where
> > all this stuff is defined and supported for all linux architectures.
> > So I think migrating from <sys/ptrace.h> to <linux/ptrace.h> is the right
> > way to go.
> 
> Something tells me that we _will_ get bitten by header include problems
> if we start including more asm/* and linux/* stuff. Every now and again
> as new kernels are released there are breakage in their headers.
> Typically easily fixable, yes, but still, it's a PITA.

Yes, this is a risk of using linux/* headers.

> Defining a correct structure ourselves has no such problems.

Yes, but we will have to do it for each linux arch.

> It's not like this structure is going to ever change.

We already do not quite rely upon sys/ptrace.h (see e.g. those multitple
PTRACE_* definitions in defs.h).  If we have to avoid linux/ptrace.h as well,
we might end up with homegrown ptrace.h-like files.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110826/86a2a924/attachment.bin>