preparing to 4.5.19 release

[Mike Frysinger]

On Thursday 08 October 2009 21:09:22 Mike Frysinger wrote:
> On Thursday 08 October 2009 20:33:31 Frederik Schüler wrote:
> > On Friday 09 October 2009 01:14:13 Dmitry V. Levin wrote:
> > > On sparc, it is defined as "static struct regs regs;"
> > > Nothing has changed in this area since v4.5.18.
> >
> > Yes, still barfing:
> >
> > gcc -DHAVE_CONFIG_H -I. -I.. -Ilinux/sparc -I../linux/sparc -Ilinux
> >  -I../linux -Wall -g -O2 -MT syscall.o -MD -MP -MF .deps/syscall.Tpo -c
> > -o syscall.o ../syscall.c
> > ../syscall.c: In function ‘get_scno’:
> > ../syscall.c:1192: error: invalid use of undefined type ‘struct regs’
> > ../syscall.c:1234: error: invalid use of undefined type ‘struct regs’
> > ../syscall.c:1234: warning: format ‘%08x’ expects type ‘unsigned int’,
> > but argument 3 has type ‘long unsigned int’
> >
> > (sid)fs at smetana:~/strace-4.5.19$ uname -a
> > Linux smetana 2.6.26-2-sparc64-smp #1 SMP Thu Aug 20 16:48:42 UTC 2009
> >  sparc64 GNU/Linux
> > (sid)fs at smetana:~/strace-4.5.19$ gcc --version
> > gcc (Debian 4.3.4-4) 4.3.4
> > Copyright (C) 2008 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> > NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> 
> not related to the running kernel or gcc/glibc.  'struct regs' comes from
> asm/regs*.h which comes from the kernel headers.  2.6.28 and older
>  installed it, but it was killed off as "useless" during 2.6.29
>  development.  presumably you're using newer kernel headers version.
> 
> going by arch/sparc/kernel/ptrace_*.c, looks like it should be switched to
> struct pt_regs as asm/ptrace.h is still installed.

i thought learning another ptrace abi would be neat, so ive converted the code 
from 'struct regs' to 'struct pt_regs', but i think the sparc kernel headers 
are a little wonky here.  if you look at the UREG_XX values, they appear to 
all be off by one, and they declare the o registers as i registers.

compare the 32 and 64 bit versions of struct pt_regs to struct regs and you'll 
see that the fields all line up, but for some reason pt_regs.u_regs[UREG_G0] 
actually refers to g1 as in reg.r_g1.  that is why in the attached patch 
register names get changed.  strace still runs fine, but the new code doesnt 
make me happy.  it should however work on both sparc32 and sparc64 userland.

looking at gdb shows that they use sys/ucontext.h from glibc to provide the 
gregset_t type (which is really just a simple array -- they rely on the size 
being correct for the ptrace call).  this header also provides REG_xx defines 
for sparc32 to index this array and the nice thing is that it appears to 
actually line up correctly -- g1 is g1 and o0 is o0.  the downside is that the 
sparc64 api uses diff define names for indexing (MC_xx), and it apparently 
relies on sparc32 layout (so i guess it assumes PTRACE_GETREGS will always be 
used as opposed to PTRACE_GETREGS64).  you can tell this as the 32bit abi has 
the state/pc regs first followed by the g/o regs while the 64bit abi has the 
state/pc regs after the g/o regs.  in turn, this would prevent a pure 64bit 
kernel and userland combo.

perhaps the sanest thing is to use pt_regs from the kernel, but then define 
our own set of defines for indexing the u_regs array.  call them U_REG_xx to 
avoid conflicting with the header.  and we stick a note in there about why we 
arent using UREG_xx from the kernel.  this way the strace sparc code would 
reflect the calling convention actually in use -- g1 is the syscall number and 
o0..o5.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strace-sparc-ptrace.patch
Type: text/x-patch
Size: 7535 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20091009/62392317/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20091009/62392317/attachment-0001.bin>