This one has 6.1.0? so we should probably decide what to do with this bug/RFE.

The original issue still holds for RHEL6.1 candidate systemtap. Shall me move
this to 6.2, close this for good, or is here a change this could still go in?

After looking at this one for a bit, this appears to be a testcase problem only, not a real systemtap problem.  The code that fails to compile comes from the testsuite itself, not a systemtap tapset.  Here's the failing code from testsuite/systemtap.context/usymbols.exp:

====
set testscript {
    probe syscall.rt_sigaction, syscall.rt_sigaction32? {
      if (pid() == target() && execname() == "%s") {
	  handler = user_long(&$act->sa_handler); // Note user address.
	  printf("handler: %%s (%%s)\n", usymname(handler), umodname(handler));
      }
    }
}
====

On an x86_64 system (where the test works), you'll see this:

# kernel.function("sys_rt_sigaction@kernel/signal.c:2638") $sig:int $act:struct sigaction const* $oact:struct sigaction* $sigsetsize:size_t $new_sa:struct k_sigaction $old_sa:struct k_sigaction

On a ppc system, you'll see this:

# stap -L 'kernel.function("sys_rt_sigaction")'
kernel.function("SyS_rt_sigaction@kernel/signal.c:2565") $sig:long int $act:long int $oact:long int $sigsetsize:long int

On ppc/s390x systems, syscall wrappers are used, which end up converting all the arguments into 'long int's.  To get around this problem, the testcase will need to be modified to use @cast() on $act.

Since this is a testcase only problem (and not a problem with systemtap itself), I'd suggest moving this to 6.2.

Moving to 6.2

I've fixed this testcase problem (and a few others) in upstream commit f7e13ea:

<http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=f7e13eadc3f666fd356ca7cdb42f1de8d53b5e4b;hp=dce37b537cd3fed15356ddca7052ed9e544d37ae>

The good news is that usymbols.exp passes on:

x86_64 (2.6.32-71.18.2.el6.x86_64)
i686 (2.6.32-71.18.2.el6.i686)
s390x (2.6.32-120.el6.s390x)

However, the 64-bit usymbols.exp test still fails on:

ppc64 (2.6.32-120.el6.ppc64)

This failure appears to be a real problem in systemtap.  I've filed sourceware.org pr12566 against this problem.

I've fixed this one for s390x upstream with commit 7c7971f:

<http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=7c7971f5df049cfec2e1d5eaee4795de0e439030>

This patch should backport cleanly to 1.6 (since it is only one line).

I'd suggest splitting this bug into a s390x bug (which we can then close) and a ppc bug (which we won't be able to close because of pr12566).

> I'd suggest splitting this bug into a s390x bug (which we can then close) and a
> ppc bug (which we won't be able to close because of pr12566).

I did that. Bug 738365 now tracks the ppc part, and is proposed for 6.3. I've modified the summary of this bug and we will use it to track the s390x part in 6.2.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    The syscall wrappers used on s390x would convert arguments
    from pointer to long int.  The usymbols test would assume those
    arguments are pointers.
Consequence
    usymbols test failed on s390x.
Fix
    The usymbols test in the SystemTap testsuite now cast the arguments
    properly.
Result
    The usymbols test now works on s390x.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1517.html