preparing to 4.5.19 release

Fri Oct 9 11:42:19 UTC 2009

Hi!

thanks fot the patch, with a small fix, the 32bit strace binary on sparc builds 
now:

diff --git a/util.c b/util.c
index c96eb0a..ddb7195 100644
--- a/util.c
+++ b/util.c
@@ -83,7 +83,9 @@
 # define fpq kernel_fpq
 # define fq kernel_fq
 # define fpu kernel_fpu
+# ifdef HAS_ASM_REG_H
 # include <asm/reg.h>
+# endif
 # undef fpq
 # undef fq
 # undef fpu

but the 64bit binary fails:

gcc -m64 -DHAVE_CONFIG_H -I. -I.. -Ilinux/sparc64 -I../linux/sparc64 -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:1177: error: ‘struct pt_regs’ has no member named ‘pc’
make[2]: *** [syscall.o] Error 1
make[2]: Leaving directory `/home/fs/strace-4.5.19/build64'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/fs/strace-4.5.19/build64'
make: *** [stamp-build64] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Best regards
Frederik Schüler


On Friday 09 October 2009 07:34:30 Mike Frysinger wrote:
> 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
> 

-- 
ENOSIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20091009/94c69b35/attachment.bin>
