[Bug runtime/4037] New: make staprun 32/64-bit interoperable

[Bug runtime/4037] New: make staprun 32/64-bit interoperable

[fche at redhat dot com]

Please investigate why a 32-bit staprun fails to work against a 64-bit kernel. 
While such installations may be unusual (i386 on x86_64, ppc on ppc64),
if we can support, we should.  At the moment we're erroring out with
   ERROR: staprun is compiled with NN-bit pointers and the kernel uses MM-bit.

-- 
           Summary: make staprun 32/64-bit interoperable
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[hunt at redhat dot com]

------- Additional Comments From hunt at redhat dot com  2007-02-14 02:10 -------
(In reply to comment #0)
> Please investigate why a 32-bit staprun fails to work against a 64-bit kernel. 

I intentionally disabled it because it was making a lot of code very messy. Also
I thought it provided an additional check that the systemtap you were attempting
to run was configured and compiled correctly.

The code that parses the kernel and module symbols and passes those back to the
kernel module for storage passes pointers and structures containing pointers. If
staprun has to dynamically detect mismatches and still work, that means more
complicated and potentially slower and buggier code. Still, it can be done and
isn't really a big deal, but what is the motivation?  I am confused about how
this situation occurred and why it is desireable to have 32-bit stapruns work on
64-bit kernels.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-02-14 02:28 -------
> I intentionally disabled it because it was making a lot of code very messy.

Indeed, which made sense in the absence of a target-neutral "wire protocol"
between the kernel and staprun.  That is in effect what I am proposing
be developed.  Consider it an enhancement if you like.

> [...]  I am confused about how this situation occurred and why it is
> desirable to have 32-bit stapruns work on 64-bit kernels.

At the moment, the issue arises on "multilib" (really, multi-ISA) architectures
where a kernel can run more than one type of binary transparently.  Hence the
wrong staprun might get installed, even though they both would "work" as far
as being executable is concerned.  This gets even more entertaining should the
same machine be equipped to run either 32- or 64-bit kernel, with a primarily 
32-bit userspace.  It would be nice to avoid requiring reinstalling staprun
just because one rebooted.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-14 02:28:01
               date|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[hunt at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |hunt at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|hunt at redhat dot com      |systemtap at sources dot
                   |                            |redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2009-11-16 20:47 -------
I've tested this issue for x86/x86_64, by testing 32-bit x86 binaries on an
64-bit x86_64 system.  To ensure I was testing 32-bit executables, I built x86
rpms on the x86 system, then installed them on the x86_64 system.

The testsuite results looked very similar to 64-bit testsuite results.

Looking at the message definitions in runtime/transport/transport_msgs.h, it
appears that they all are in the form int32_t/int64_t which looks correct. 
There are no plain 'int' or 'long' types there.

Using '-DDEBUG_SYMBOLS' to see what sort of addresses the 32-bit staprun is
sending the kernel shows this:

# stap -DDEBUG_SYMBOLS -e 'probe kernel.function("sys_open") { printf("open\n") }'
(02:29:45 PM) dsmith: _stp_module_relocate:79: kernel, _stext, 30690
(02:29:45 PM) dsmith: _stp_module_relocate:107: address=ffffffff80031690

That address is a 64-bit address, which is correct.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-11-18 01:12 -------
On powerpc, I get similar result.  32-bit .ppc RPMs (including stap/staprun)
do seem to operate correctly with the 64-bit kernel.

commit 47f390f removes a no-longer-needed hack.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4037] make staprun 32/64-bit interoperable

[pavan dot naregundi at in dot ibm dot com]

------- Additional Comments From pavan dot naregundi at in dot ibm dot com  2009-11-20 08:38 -------
Tested 32-bit systemtap on F12-ppc64 and tests are running fine. Here are the
results for the run,

  === systemtap Summary ===

# of expected passes            783
# of unexpected failures        71
# of unexpected successes       8
# of expected failures          205
# of unknown successes          1
# of known failures             5
# of untested testcases         39
# of unsupported tests          4


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4037

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.