[PATCH] Use PTRACE_GETREGS on i386

[Dmitry V. Levin]

On Fri, Aug 26, 2011 at 07:32:17PM +0200, Denys Vlasenko wrote:
> On Fri, 2011-08-26 at 20:36 +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 25, 2011 at 12:10:06PM +0200, Denys Vlasenko wrote:
> > >  #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;
> > 
> > strace is not going to call PTRACE_GETREGS with different regs structures,
> > so is there any use to include the architecture name to the structure
> > name?
> 
> There *is* a reason to name it i386_regs: it makes it possible
> to easily find its uses.

It is called just "regs" three times in this file already: on ARM, AVR32,
SPARC and SPARC64:
$ grep -Fn 'static struct pt_regs' syscall.c
730:static struct pt_regs regs;
735:static struct pt_regs regs;
737:static struct pt_regs regs;

Of course pt_regs field names may differ, but why should we introduce a
difference in naming if there are no differences in use?
Or am I missing something?

> For example,  Alpha, Blackfin and SH all have "static long r0". How can
> I quickly find only Alpha's usages of r0? There is no easy way to do it.
> I'd rather have them named alpha_r0, bfin_r0, sh_r0.

I'd rather kick them out in favour of pt_regs, so it would be regs.r0 instead.
Or would you like to call them alpha_regs.r0, bfin_regs.r0 and sh_regs.r0?


-- 
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/a3d78b06/attachment.bin>