[Bug tapsets/4475] New: ia64 syscall tapset issues.

[Bug tapsets/4475] New: ia64 syscall tapset issues.

[wcohen at redhat dot com]

On ia64 some of the testsuite/systemtap.syscall/syscall.exp tests are not
working on ia64 rhel4u5. The tests that appeared to failed because some function
parameter was reported as "<unknown>" or "UNKNOWN". It appears that some of the
arguments passed into the function were missing. This seems to be a problem
mostly for "open()". An example on acct test output was:

acct: acct (<unknown>) = -1 (EPERM)

was expecting to match:

acct: acct \("foobar"\) = -[\-0-9]+

For a couple of the tests, alarm and rt_signal some functions are not being
called. For forkwait it "fork_kernel_thread()" is used rather than "clone()"

A summary of the ia64 test results problems:


FAIL: 64-bit acct	unknown arg on acct
FAIL: 64-bit alarm	unknown arg on nanosleep , no alarm or pause calls
FAIL: 64-bit chmod	unknown arg on open
FAIL: 64-bit dir	unknown arg on open
FAIL: 64-bit forkwait (actually because of fork_kernel_thread() used
		instead of "clone")
FAIL: 64-bit link	unknown arg on link
FAIL: 64-bit mmap	unknown arg on open
FAIL: 64-bit mount	unknown arg on mount
FAIL: 64-bit net1	missing arg for fcntl cmd_str
FAIL: 64-bit openclose	unknown arg on open, bogus arg on close
FAIL: 64-bit readwrite	unknown arg on open
FAIL: 64-bit rt_signal	no rt_sigprocmask calls
UNSUPPORTED: signal not supported on this arch
FAIL: 64-bit stat	unknown arg on open
FAIL: 64-bit statfs	pointers values don't match

-- 
           Summary: ia64 syscall tapset issues.
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: wcohen at redhat dot com
  GCC host triplet: ia64


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[wcohen at redhat dot com]

------- Additional Comments From wcohen at redhat dot com  2007-05-09 15:41 -------
The syscall.pipe needed to be fixed for ia64 for the systemcall tests to build
and the issues in this report to be visible.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |4471


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[wcohen at redhat dot com]

-- 
Bug 4475 depends on bug 4471, which changed state.

Bug 4471 Summary: ia64 llinux kernel sys_pipe() arguments different than other processors.
http://sourceware.org/bugzilla/show_bug.cgi?id=4471

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[wcohen at redhat dot com]

------- Additional Comments From wcohen at redhat dot com  2007-05-18 17:17 -------
Created an attachment (id=1850)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1850&action=view)
script to look $filename of open

It appears that the probes are getting bogus values for the pointers. Tried a
simple example for the open and looked at the value of $filename. $filename
doesn't appear to be pointing at the expected location for the user space
string. Compiled the openclose.c program and took a look at the memory map:

$ pmap 27467
27467:	 /home/wcohen/openclose
0000000000000000     16K r----	  [ anon ]
2000000000000000    192K r-x--	/lib/ld-2.3.4.so
200000000003c000     32K rw---	/lib/ld-2.3.4.so
2000000000054000   2384K r-x--	/lib/tls/libc-2.3.4.so
20000000002a8000     48K -----	/lib/tls/libc-2.3.4.so
20000000002b4000     32K rw---	/lib/tls/libc-2.3.4.so
20000000002bc000     64K rw---	  [ anon ]
4000000000000000     16K r-x--	/home/wcohen/openclose
6000000000000000     16K rw---	/home/wcohen/openclose
600007ffff840000     16K rw---	  [ anon ]
60000fffff7e8000    336K rw---	  [ stack ]
a000000000000000    128K r-x--	  [ anon ]
 total		   3280K

Using objdump found the strings located:

Contents of section .rodata:
 4000000000000ca0 666f6f62 61723100 666f6f62 61723200  foobar1.foobar2.
 4000000000000cb0 2f00	 

When run

$ /home/wcohen/stap_testing_200705161953/install/bin/stap   open.stp -c
"./openclose" |grep openclose
openclose: open (0xa000000100766080)
openclose: open (<unknown>, O_RDONLY) = 4
openclose: open (0xa000000100766080)
openclose: open (<unknown>, O_RDONLY) = 4
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_WRONLY|O_CREAT|O_TRUNC, 01200000000040031457640)
= 4
openclose: open (0x0000000000000000)
openclose: open (NULL, O_WRONLY|O_CREAT, 01200000000040035460200) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_RDONLY) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_RDWR) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_WRONLY|O_APPEND) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_RDWR|O_DIRECT) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_RDWR|O_NOATIME|O_SYNC) = 5
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_WRONLY) = -21 (EISDIR)
openclose: open (0x0000000000030001)
openclose: open (<unknown>, O_WRONLY|O_CREAT|O_EXCL, 01200000000040031457640) =
-17 (EEXIST)

The values for $filename do not look correct.

-- 


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[wcohen at redhat dot com]

------- Additional Comments From wcohen at redhat dot com  2007-06-11 20:33 -------
When running a 2.6.22-rc4 kernel built on RHEL4 a similar problem is encountered
for systemtap.samples/tcptest.stp. The value for sock (local variable $sk) in
probe tcp.sendmsg appears to be zero. This causes the proble to fail.

-- 


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[hunt at redhat dot com]

------- Additional Comments From hunt at redhat dot com  2007-07-27 15:47 -------
It would be nice to understand more about this problem.  How widespread is it? 
Why the problems accessing userspace for IA64?  This does not appear to be a
syscalls tapset issue at all.

-- 


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[shaohua dot li at intel dot com]

------- Additional Comments From shaohua dot li at intel dot com  2007-11-13 08:40 -------
can you retest it? In my test, it appears everything is fine.

pcscd: open (0x2000000001b00f37)
pcscd: open ("/dev/bus/usb/002/001", O_RDWR) = 6
hald-addon-stor: open (0x60000fffffe0fdfc)
hald-addon-stor: open ("/dev/hda", O_RDONLY|O_EXCL|O_NONBLOCK) = 4
pcscd: open (0x200000000008b410)
pcscd: open ("/dev/bus/usb", O_RDONLY|O_DIRECTORY|O_NONBLOCK) = 6

-- 


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

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

[Bug tapsets/4475] ia64 syscall tapset issues.

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2010-01-14 17:04 -------
On current rhel5 kernels (2.6.18-164.9.1.el5), this problem no longer occurs, so
I'm closing this as WONTFIX.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

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