Bug 559599 - Errata testing: buildok/fortyfive.stp FAIL (ia64)
Errata testing: buildok/fortyfive.stp FAIL (ia64)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: systemtap (Show other bugs)
5.5
ia64 Linux
low Severity medium
: rc
: ---
Assigned To: Frank Ch. Eigler
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-28 10:15 EST by Petr Muller
Modified: 2016-09-19 22:06 EDT (History)
3 users (show)

See Also:
Fixed In Version: systemtap-1.3-5.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 07:10:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Muller 2010-01-28 10:15:52 EST
Description of problem:
buildok/fortyfive.stp fails to build with 5.5's systemtap. The 5.4
systemtap builds the same testcase, so this can be considered as Regression.

Version-Release number of selected component (if applicable):

Distro: RHEL5.5-Server-20100122.nightly
Running kernel: 2.6.18-185.el5
Architectures: ia64 s390x ppc
Systemtap: systemtap-1.1-1.el5
Testsuite: systemtap-testsuite-1.1-1.el5

How reproducible:
Always

Steps to Reproduce:
1. install systemtap-testsuite-1.1-1.el5
2. cd /usr/share/systemtap/testsuite/
3. # stap -v -p4 buildok/fortyfive.stp

Actual results on ia64 (ia64 is different from s390x and ppc):
# stap -v -p4 buildok/fortyfive.stp
Pass 1: parsed user script and 64 library script(s) using 30016virt/21984res/3872shr kb, in 266usr/6sys/272real ms.
semantic error: unresolved arity-0 function: identifier 'asmlinkage' at /usr/share/systemtap/tapset/nd_syscalls.stp:889:2
        source:         asmlinkage()
                        ^
semantic error: unresolved arity-1 function: identifier 'int_arg' at :890:11
        source:         status = int_arg(1)
                                 ^
Pass 2: analyzed script: 5 probe(s), 70 function(s), 3 embed(s), 2 global(s) using 100992virt/76368res/45280shr kb, in 361usr/108sys/472real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option

Actual results on s390x and ppc:
# stap -v -p4 buildok/fortyfive.stp
Pass 1: parsed user script and 65 library script(s) using 24260virt/19628res/2092shr kb, in 370usr/10sys/394real ms.
Pass 2: analyzed script: 5 probe(s), 17 function(s), 3 embed(s), 3 global(s) using 68340virt/53160res/26244shr kb, in 380usr/20sys/390real ms.
Pass 3: translated to C into "/tmp/staplEr50g/stap_8fb2136fc22da2d7ad661b827e5de39e_11164.c" using 68340virt/54180res/27264shr kb, in 830usr/20sys/853real ms.
cc1: warnings being treated as errors
/tmp/staplEr50g/stap_8fb2136fc22da2d7ad661b827e5de39e_11164.c: In function ‘function__stp_get_register_by_offset’:
/tmp/staplEr50g/stap_8fb2136fc22da2d7ad661b827e5de39e_11164.c:1084: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’
make[1]: *** [/tmp/staplEr50g/stap_8fb2136fc22da2d7ad661b827e5de39e_11164.o] Error 1
make: *** [_module_/tmp/staplEr50g] Error 2
Pass 4: compiled C into "stap_8fb2136fc22da2d7ad661b827e5de39e_11164.ko" in 3450usr/400sys/3866real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.

Expected results (the identical testcase, RHEL5.4 systemtap):
# stap -v -p4 buildok/fortyfive.stp
Pass 1: parsed user script and 52 library script(s) in 310usr/10sys/332real ms.
Pass 2: analyzed script: 4 probe(s), 6 function(s), 3 embed(s), 1 global(s) in 340usr/220sys/546real ms.
Pass 3: translated to C into "/tmp/stapsyoLce/stap_3535328214a222ae8e0ba1c7c22f3990_7104.c" in 460usr/210sys/680real ms.
/root/.systemtap/cache/35/stap_3535328214a222ae8e0ba1c7c22f3990_7104.ko
Pass 4: compiled C into "stap_3535328214a222ae8e0ba1c7c22f3990_7104.ko" in 2310usr/260sys/2484real ms.
Comment 1 David Smith 2011-01-28 10:38:00 EST
For ia64, the problem is similar to bug #669740.  The tapset/target_set.stp file was switched from using syscall probes to nd_syscall syscall probes (which map to dwarfless 'kprobe.function' probes).  The ia64 platform doesn't support dwarfless probes (see upstream bug 6971 <http://sources.redhat.com/bugzilla/show_bug.cgi?id=6971>).

The easiest solution for ia64 would be to extend the patch that fixed bug #669740 and fall back to syscall probes for ia64.
Comment 3 David Smith 2011-01-28 14:03:37 EST
From testing systemtap-1.3-4.el5 on s390x, buildok/fortyfive.stp no longer gets a compilation error.  So certainly for s390x this is CLOSED/CURRENTRELEASE.  I couldn't find a ppc64 machine to test on, but I'd bet that buildok/fortyfive.stp works with systemtap-1.3-4.el5 there also.

That only leaves us with ia64, where buildok/fortyfive.stp is still broken with systemtap-1.3-4.el5.  This has been fixed upstream by applying the following 2 commits (which will need to be backported to 1.3):

commit 4ec30a2 (which fixed bug #669740):

<http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=patch;h=4ec30a2e5dd462bddce36728de7332fd0942bd31>

commit 1916e83 (which fixes the ia64 specific problem):

<http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=patch;h=1916e8381d5c7d6a06d6b19abeca32ad2f1cef78>
Comment 8 errata-xmlrpc 2011-07-21 07:10:57 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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

Note You need to log in before you can comment on or make changes to this bug.