Bug 723541

Summary: --remote option failing on i386,ppc,s390x
Product: Red Hat Enterprise Linux 6 Reporter: Petr Muller <pmuller>
Component: systemtapAssignee: Josh Stone <jistone>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: fche, jistone, mjw, ohudlick, scox, wcohen
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 15:18:19 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 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