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 723541 - --remote option failing on i386,ppc,s390x
Summary: --remote option failing on i386,ppc,s390x
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Josh Stone
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-20 14:15 UTC by Petr Muller
Modified: 2016-09-20 02:08 UTC (History)
6 users (show)

Fixed In Version: systemtap-1.6-1.el6
Doc Type: Bug Fix
Doc Text:
Cause The --remote did not use the proper canonical names for the i686, ppc, and s390x. Consequence SystemTap stap command would fail to build instrumentation when the --remote options was used for i686, ppc, and s390x. Fix Systemtap fixed the session code to properly copy kernel/arch information and avoid using implicit behavior for the --remote option. Result SystemTap stap command builds instrumentation when the --remote options is for i686, ppc, and s390x.
Clone Of:
Environment:
Last Closed: 2011-12-06 15:18:19 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-07-20 14:15:22 UTC 
Description of problem:
On these three architectures, --remote option fails to build the module:

i386:
# stap --remote root@$SERVERS -v ktest.stp 
Pass 1: parsed user script and 73 library script(s) using 22164virt/13260res/2360shr kb, in 230usr/10sys/248real ms.
Pass 2: analyzed script: 5 probe(s), 2 function(s), 22 embed(s), 0 global(s) using 186220virt/28748res/3276shr kb, in 2020usr/870sys/3052real ms.
Pass 3: translated to C into "/tmp/stapixgULV/stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.c" using 186220virt/32680res/7200shr kb, in 960usr/20sys/981real ms.
Makefile:558: /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile: No such file or directory
make: *** No rule to make target `/usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile'.  Stop.
Pass 4: compiled C into "stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.ko" in 90usr/40sys/124real ms.
Pass 4: compilation failed.  Try again with another '--vp 0001' option.
Segmentation fault (core dumped)

Indeed, there is no i686 directory in /usr/src/kernels/v-r/arch:
# ls /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/
alpha     cris   Kconfig    microblaze  powerpc  sparc
arm       frv    m32r       mips        s390     um
avr32     h8300  m68k       mn10300     score    x86
blackfin  ia64   m68knommu  parisc      sh       xtensa

ppc:
# stap --remote root@$SERVERS -v ktest.stp 
Pass 1: parsed user script and 73 library script(s) using 39168virt/31232res/9088shr kb, in 260usr/10sys/274real ms.
semantic error: ELF machine powerpc| (code 21) mismatch with target ppc64 in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.ppc64/vmlinux'
semantic error: no match while resolving probe point syscall.fcntl
Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 146496virt/32960res/9920shr kb, in 10usr/0sys/32real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.
Segmentation fault (core dumped)

s390x:
# stap --remote root@$SERVERS -v ktest.stp 
Pass 1: parsed user script and 73 library script(s) using 31552virt/21696res/2952shr kb, in 180usr/10sys/195real ms.
semantic error: ELF machine s390| (code 22) mismatch with target s390x in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.s390x/vmlinux'
semantic error: no match while resolving probe point syscall.fcntl
Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 105964virt/22992res/3492shr kb, in 10usr/0sys/8real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.
Segmentation fault (core dumped)

Version-Release number of selected component (if applicable):
systemtap-debuginfo-1.4-6.el6_1.2

How reproducible:
seems always
  
Actual results:
failure to compile a stap kernel module

Expected results:
everything works, as on x86_64

Additional info:
- In all cases, SERVERS contained a valid --remote target: identical kernel{,-devel} packages and systemtap-runtime version, and accesible by ssh.
- Does not happen on x86_64
- Also, this seems to be fixed in current upstream systemtap. Filing this bug so
we can track if it is fixed in 6.2.
- The segmentation fault is filed as separate bug 723536
Comment 1 Josh Stone 2011-07-20 23:01:39 UTC 
The same commit abc15290 which fixed the SEGV probably also fixed this bug, because it also makes sure that we normalize the remote target arch to match what the kernel build and ELF checks are expecting.
Comment 4 William Cohen 2011-11-11 21:39:15 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:
Cause
    The --remote did not use the proper canonical names for the i686, ppc,
    and s390x.
Consequence
    SystemTap stap command would fail to build instrumentation
    when the --remote options was for i686, ppc, and s390x.
Fix
    Systemtap fixed the session code to properly copy kernel/arch
    information and avoid using implicit behavior for the --remote option.
Result
    SystemTap stap command builds instrumentation
    when the --remote options is for i686, ppc, and s390x.
Comment 5 William Cohen 2011-11-11 21:57:44 UTC 
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -3,7 +3,7 @@
     and s390x.
 Consequence
     SystemTap stap command would fail to build instrumentation
-    when the --remote options was for i686, ppc, and s390x.
+    when the --remote options was used for i686, ppc, and s390x.
 Fix
     Systemtap fixed the session code to properly copy kernel/arch
     information and avoid using implicit behavior for the --remote option.
Comment 6 errata-xmlrpc 2011-12-06 15:18:19 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.