Hide Forgot
Description of problem: The release is rhel6.2 0822.5 tree with kernel 2.6.32-192.el6. systemtap version 1.6-2.el6. sdt.exp always fails at those two points on ppc64 system: Executing on host: gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include +-Wall -Wextra -Werror -DSTAP_SDT_V2 -O2 -lm -o sdt.c.exe.0 (timeout = 300) spawn -ignore SIGHUP gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include +-Wall -Wextra -Werror -DSTAP_SDT_V2 -O2 -lm -o sdt.c.exe.0^M PASS: compiling sdt.c -O2 V2_uprobe executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/sdt.stp sdt.c.exe.0 -c ./sdt.c.exe.0 FAIL: sdt -O2 V2_uprobe line 2: expected "1" Got "17591182638944" Executing on host: gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include +-Wall -Wextra -Werror -DSTAP_SDT_V2 -O3 -lm -o sdt.c.exe.1 (timeout = 300) spawn -ignore SIGHUP gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include +-Wall -Wextra -Werror -DSTAP_SDT_V2 -O3 -lm -o sdt.c.exe.1^M PASS: compiling sdt.c -O3 V2_uprobe executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/sdt.stp sdt.c.exe.1 -c ./sdt.c.exe.1 FAIL: sdt -O3 V2_uprobe line 2: expected "1" Got "17591513502544" Something odd is happening when the test executable is optimized. # stap -w /root/src/testsuite/systemtap.base/sdt.stp sdt.c.exe.1 -c ./sdt.c.exe.1 _ 17591222666032 17591222666032 268537368 17591222666032 268537368 1 17591222666032 268537368 1 17591222667128 17591222666032 268537368 1 17591222667128 17591222667144 17591222666032 268537368 1 17591222667128 17591222667144 17591222667448 17591222666032 268537368 1 17591222667128 17591222667144 17591222667448 268504560 17591222666032 268537368 1 17591222667128 17591222667144 17591222667448 268504560 0 17591222666032 268537368 1 17591222667128 17591222667144 17591222667448 268504560 0 268504528 17591222666032 268537368 1 17591222667128 17591222667144 17591222667448 268504560 0 268504528 551765933400 Version-Release number of selected component (if applicable): systemtap 1.6-2.el6 kenrel 2.6.32-192.el6 How reproducible: always Steps to Reproduce: 1. install rhel6.2 beta on s390x 2. cd /usr/share/systemtap/testsuite;make installcheck RUNTESTFLAGS="--debug sdt.exp" 3. Actual results: Expected results: Additional info:
> 1. install rhel6.2 beta on s390x Sorry, should be on ppc64 system.
The STAP_SDT_V2 tests are compatibility tests as the default is now STAP_SDT_V3. stap accesses probe args by storing the asm operand equivalent of the arg. ppc and s390 have ambiguous formats for registers and constants when taken out of context, i.e. 1 could be register 1 or the constant 1 depending on how it is used. stap doesn't have enough info to determine this and it erroneously assumed it was register 1. The circumstances where stap makes this incorrect assumption are: -The application has STAP_SDT_V2 probes, i.e. an older application not rebuilt with STAP_SDT_V3 -The probe argument was either a constant less than 31 or a constant variable with a value less than 31 that has been constant folded STAP_SDT_V3 added info to the stored asm operand so register 1 and constant 1 can be disambiguated so current stap doesn't have this problem.
The upstream patch '1fbbc4d3b4' XFAILS these failures.
We can backport the testsuite-xfail patch if desired. The underlying problem with the obsolete sdt.h version is not practical to correct however, so CANTFIX that part. Opinions about whether the xfail path is worth doing?
(In reply to comment #5) > We can backport the testsuite-xfail patch if desired. The underlying problem > with the obsolete sdt.h version is not practical to correct however, so CANTFIX > that part. Opinions about whether the xfail path is worth doing? Yes, I think it is worth doing. Thanks.
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 Some systemtap testsuite sdt.exp ran tests with -DEXPERIMENTAL_KPROBE_SDT, an older, obsolete mechanism. No existing applications should be built with this obsolete mechanism and there is little reason in include these in the test results. Consequence On some architectures the tests using the -DEXPERIMENTAL_KPROBE_SDT would fail. Fix The sdt.exp now mark the problematic -DEXPERIMENTAL_KPROBE_SDT that fail as XFAIL. Result The sdt.exp tests using -DEXPERIMENTAL_KPROBE_SDT that fail are no longer included in the FAIL results.
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