RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 691763 - systemtap.base/cxxclass.exp: 2 PASS -> 1 FAIL on ppc64
Summary: systemtap.base/cxxclass.exp: 2 PASS -> 1 FAIL on ppc64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.1
Hardware: ppc64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Frank Ch. Eigler
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
: 692461 (view as bug list)
Depends On:
Blocks: 682670 702988 750924
TreeView+ depends on / blocked
 
Reported: 2011-03-29 12:26 UTC by Petr Muller
Modified: 2016-09-20 02:07 UTC (History)
5 users (show)

Fixed In Version: systemtap-1.6-1.el6
Doc Type: Bug Fix
Doc Text:
On some architectures, systemtap may not find certain functions to probe or variables to fetch, in highly optimized code. You may be able to apply less optimization, or change the placement of the probes to a higher call site.
Clone Of:
: 750924 (view as bug list)
Environment:
Last Closed: 2011-12-06 15:17:47 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1517 0 normal SHIPPED_LIVE systemtap bug fix and enhancement update 2011-12-06 00:50:46 UTC

Description Petr Muller 2011-03-29 12:26:35 UTC 
Description of problem:
The RHEL6.1 candidate systemtap packages has 1 FAIL, 1 PASS in
systemtap.base/cxxclass.exp testcase, while the 6.0.z systemtap has 2 PASSes
here. This happens on ppc64, it does not happen on i686, unknown on s390x and
x86_64

Version-Release number of selected component (if applicable):
Environment:
kernel-2.6.32-122.el6
elfutils-0.152-1.el6
systemtap-testsuite-1.4-4.el6

Systemtap:
systemtap-1.2-11.el6_0 PASS
systemtap-1.4-4 FAIL

How reproducible:
always

Steps to Reproduce:
1. cd /usr/share/systemtap/testsuite/
2. make RUNTESTFLAGS=systemtap.base/cxxclass.exp installcheck
3.

Actual results:
FAIL

Expected results:
PASS

Additional info:
systemtap.log.diff:
 executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp cxxclass.exe -c ./cxxclass.exe
-PASS: cxxclass
-testcase /usr/share/systemtap/testsuite/systemtap.base/cxxclass.exp completed in 8 seconds
+FAIL: cxxclass
+line 1: expected "main_enter"
+Got "semantic error: unable to find local 'arg1' near pc 0x10000608 in ProbeClass(/usr/share/systemtap/testsuite/systemtap.base/cxxclass.cxx) (alternatives: $n $v $this): identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp:23:39"
+testcase /usr/share/systemtap/testsuite/systemtap.base/cxxclass.exp completed in 3 seconds
Comment 2 Petr Muller 2011-03-31 11:49:30 UTC 
happens on s390x too
Comment 3 Frank Ch. Eigler 2011-04-06 14:52:24 UTC 
*** Bug 692461 has been marked as a duplicate of this bug. ***
Comment 4 David Smith 2011-04-13 19:55:44 UTC 
I've duplicated this one against:

kernel-2.6.32-130.el6.ppc64
systemtap-1.4-6.el6.ppc64
elfutils-0.152-1.el6.ppc64

I also tried this with HEAD systemtap and got the same result.  So, we'll have to do more investigation.
Comment 5 David Smith 2011-04-14 14:38:58 UTC 
This test failure appears related to g++ optimization.  The test uses '-O2' when compiling, which fails.  If I change this to '-O0' (no optimization), the test runs just fine.  Since gdb can't find the ProbeClass constructor or destructor when compiled with '-O2', I'm guessing the they were inlined.
Comment 6 David Smith 2011-04-14 17:58:27 UTC 
(In reply to comment #5)
> This test failure appears related to g++ optimization.  The test uses '-O2'
> when compiling, which fails.  If I change this to '-O0' (no optimization), the
> test runs just fine.  Since gdb can't find the ProbeClass constructor or
> destructor when compiled with '-O2', I'm guessing the they were inlined.

I'm seeing the exact same thing on s390x:

kernel-2.6.32-131.0.1.el6.s390x
systemtap-1.4-6.el6.ppc64
elfutils-0.152-1.el6.ppc64

Without optimization, the test works fine.
Comment 8 Frank Ch. Eigler 2011-04-19 15:54:57 UTC 
We haven't been able to diagnose this problem in time.  Adding release note blurb and deferring to rhel6.2.
Comment 9 Frank Ch. Eigler 2011-04-19 15:54:58 UTC 
    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:
On some architectures, systemtap may not find certain functions to probe or variables to fetch, in highly optimized code.  You may be able to apply less optimization, or change the placement of the probes to a higher call site.
Comment 11 Stan Cox 2011-04-20 21:06:26 UTC 
ppc64 (and probably also s390x) for sdt arguments are creating descriptors of the form .LC1@toc(2) which stap does not handle.  So it falls back to trying dwarf, but the ideal is to not rely on dwarf info.
Comment 12 Frank Ch. Eigler 2011-04-20 23:30:39 UTC 
In the case of sdt-v3 in current sys/sdt.h, there is no dwarf fallback 
for $argN possible, is there?
Comment 14 Stan Cox 2011-05-05 19:05:58 UTC 
No dwarf fallback is possible as the args don't actually exist in the C sense.

commit: 710a2a45c4 Add -DSTAP_SDT_ARG_CONSTRAINT
Comment 15 Frank Ch. Eigler 2011-06-09 20:39:30 UTC 
The upstream commit mentioned in comment #14 fixes various sdt.h test cases
by purposefully reducing the gcc optimization for the marker sites for non-x86
machines.
Comment 17 Han Pingtian 2011-08-24 04:28:07 UTC 
I can reproduce the duplicated bug692461 on s390x, with systemtap-1.6-2.el6:

make installcheck RUNTESTFLAGS='--debug systemtap.base/sdt.exp'
...

Executing on host: gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c  -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include -Wall -Wextra -Werror -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 -O2 -lm -o sdt.c.exe.0^M
PASS: compiling sdt.c -O2  uprobe
executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/sdt.stp sdt.c.exe.0 -c ./sdt.c.exe.0
FAIL: sdt -O2  uprobe
line 1: expected "_"
Got "semantic error: unable to find local 'arg1' near pc 0x80000538  in  call1 /usr/share/systemtap/testsuite/systemtap.base/sdt.c ( (alternatives: $a): identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/sdt.stp:8:18"
Executing on host: gcc /usr/share/systemtap/testsuite/systemtap.base/sdt.c  -g -isystem/usr/share/systemtap/testsuite -isystem/usr/include -Wall -Wextra -Werror -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 -O3 -lm -o sdt.c.exe.1^M
PASS: compiling sdt.c -O3  uprobe
executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/sdt.stp sdt.c.exe.1 -c ./sdt.c.exe.1
FAIL: sdt -O3  uprobe
line 1: expected "_"
Got "semantic error: unable to find local 'arg1' near pc 0x80000538  in  call1 /usr/share/systemtap/testsuite/systemtap.base/sdt.c ( (alternatives: $a): identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/sdt.stp:8:18"


And cxxclass.exp also failed on s390x, the error messages are:

Running /usr/share/systemtap/testsuite/systemtap.base/cxxclass.exp ...
Executing on host: g++ /usr/share/systemtap/testsuite/systemtap.base/cxxclass.cxx  -g -O2 -isystem/usr/share/systemtap/testsuite -isystem/usr/include -DSTAP_SDT_ARG_CONSTRAINT=nr  -lm   -o cxxclass.exe    (timeout = 300)
spawn -ignore SIGHUP g++ /usr/share/systemtap/testsuite/systemtap.base/cxxclass.cxx -g -O2 -isystem/usr/share/systemtap/testsuite -isystem/usr/include -DSTAP_SDT_ARG_CONSTRAINT=nr -lm -o cxxclass.exe^M
PASS: cxxclass.c compile
executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp cxxclass.exe -c ./cxxclass.exe
FAIL: cxxclass
line 1: expected "main_enter"
Got "semantic error: unable to find local 'arg1' near pc 0x800005e8  in  <unknown> /usr/share/systemtap/testsuite/systemtap.base/cxxclass.cxx ( (alternatives: $i $inst): identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp:13:24"
testcase /usr/share/systemtap/testsuite/systemtap.base/cxxclass.exp completed in 1 seconds
Comment 18 Petr Muller 2011-10-12 16:51:27 UTC 
Still happens on s390x: 

PASS: cxxclass.c compile
executing: stap -w /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp cxxclass.exe -c ./cxxclass.exe
FAIL: cxxclass
line 1: expected "main_enter"
Got "semantic error: unable to find local 'arg1' near pc 0x800005e8  in  <unknown> /usr/share/systemtap/testsuite/systemtap.base/cxxclass.cxx ( (alternatives: $i $inst): identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/cxxclass.stp:1

Fixed on ppc, PASSed on i686, x86_64.

Is there any chance this could be fixed in 6.2, or shall I make a bug for the s390x case?
Comment 19 Petr Muller 2011-11-02 20:24:22 UTC 
Moving to VERIFIED for ppc64 (as requested by the subject line). s390x failures are tracked in bug 750924, proposed for rhel6.3
Comment 20 errata-xmlrpc 2011-12-06 15:17:47 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.