Bug 733181
| Summary: | sdt.exp fails at sdt -O2 V2_uprobe and sdt -O3 V2_uprobe | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Han Pingtian <phan> |
| Component: | systemtap | Assignee: | Stan Cox <scox> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | czhang, fche, mjw, scox, syeghiay, wcohen |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | ppc64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemtap-1.6-4.el6 | Doc Type: | Bug Fix |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 15:18:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Han Pingtian
2011-08-25 03:17:26 UTC
> 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 |