Syscall tracing seems to be broken on s390x arch. They are failing in pass 2, with following errors: # stap buildok/syscall.stp -v Pass 1: parsed user script and 44 library script(s) in 420usr/10sys/434real ms. semantic error: unresolved arity-1 function: identifier 'pointer_arg' at /usr/share/systemtap/tapset/syscalls2.stp:3027:19 semantic error: unresolved arity-1 function: identifier 'pointer_arg' at :3029:14 semantic error: unresolved arity-1 function: identifier 'pointer_arg' at :3011:19 semantic error: unresolved arity-1 function: identifier 'pointer_arg' at :3013:14 Pass 2: analyzed script: 714 probe(s), 1866 function(s), 13 embed(s), 1 global(s) in 6660usr/360sys/7064real ms. Pass 2: analysis failed. Try again with more '-v' (verbose) options. Function 'pointer_arg' (and related functions 'int_arg', 'uint_arg', etc.) comes from tapset/ARCH/registers.stp for i386, ppc64, and x86_64. Since registers.stp doesn't exist for s390x, there is no definition for the *_arg functions. If the 'pointer_arg' type functions are only designed to be used by the nd_syscall tapset, then their use needs to be removed from syscalls2.stp.
(In reply to comment #0) ... > > Function 'pointer_arg' (and related functions 'int_arg', 'uint_arg', etc.) comes > from tapset/ARCH/registers.stp for i386, ppc64, and x86_64. Since registers.stp > doesn't exist for s390x, there is no definition for the *_arg functions. > > If the 'pointer_arg' type functions are only designed to be used by the > nd_syscall tapset, then their use needs to be removed from syscalls2.stp. The *_arg functions are intended to be generally useful -- especially in conjunction with dwarfless probing, where there's no other practical way to refer to args. The problem is that -- as you've noted -- they haven't been ported to s390 or ia64 (or arm). So it would probably be best to purge the syscall tapset of calls to these functions.
David tracked it down to my commit: commit e483d9dfa614ee17b488df7224ee22a0f7dc9386 Author: Mark Wielaard <mwielaard@redhat.com> Date: Wed May 21 16:12:17 2008 +0200 Use pointer_arg to fetch arguments for syscall.utime and compat_utime. diff --git a/tapset/ChangeLog b/tapset/ChangeLog index a0f14de..2c4ba4d 100644 --- a/tapset/ChangeLog +++ b/tapset/ChangeLog @@ -1,3 +1,8 @@ +2008-05-21 Mark Wielaard <mwielaard@redhat.com> + + * syscalls2.stp (syscall.utime): Use pointer_arg to fetch arguments. + (syscall.compat_utime): Likewise. This was done to fix this issue: http://sourceware.org/ml/systemtap/2008-q2/msg00397.html FAIL: semok/nodwf02.stp FAIL: semok/nodwf05.stp So I changed these utime calls to also work with dwarfless probes: http://sourceware.org/ml/systemtap/2008-q2/msg00399.html A bit more analysis is in: http://sourceware.org/ml/systemtap/2008-q2/msg00410.html
I reverted the change mentioned in comment #2. It also caused FAIL: 32-bit futimes and FAIL: 32-bit stat on x86 (but not x86_64 in 32-bit mode). With this reverted they PASS on all architectures I tested on. Both semok/nodwf02.stp and semok/nodwf05.stp still PASS. No regressions on x86_64 2.6.18-92.1.13.el5 and i686 2.6.26.5-28.fc8. commit b5223457bca23f214fb35f3ffdc372bf67cfe190 Author: Mark Wielaard <mjw@redhat.com> Date: Thu Oct 23 20:34:42 2008 +0200 Don't use pointer_arg to fetch arguments for syscall utime and compat_utime. Please retest on s390x.
> Please retest on s390x. I've tested this on s390x, and it seems to work fine.