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)f...@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)f...@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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
