From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23920 invoked by alias); 20 Apr 2009 19:15:38 -0000 Received: (qmail 23909 invoked by uid 22791); 20 Apr 2009 19:15:37 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 19:15:32 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n3KJFVGH018484 for ; Mon, 20 Apr 2009 15:15:31 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3KJFUJZ029325 for ; Mon, 20 Apr 2009 15:15:30 -0400 Received: from localhost.localdomain (dst61.hsv.redhat.com [172.16.16.175]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3KJFTpO022619; Mon, 20 Apr 2009 15:15:30 -0400 Message-ID: <49ECC9D4.2050602@redhat.com> Date: Mon, 20 Apr 2009 19:15:00 -0000 From: David Smith User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Roland McGrath CC: Systemtap List Subject: Re: utrace syscall arguments References: <49E8967F.6000604@redhat.com> <20090417183904.DF270FC35F@magilla.sf.frob.com> <49E8F25E.6080506@redhat.com> <20090417212956.7C6C7FC35F@magilla.sf.frob.com> <20090417221207.EC4A0FC35F@magilla.sf.frob.com> <49EC810B.5020407@redhat.com> In-Reply-To: <49EC810B.5020407@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00342.txt.bz2 David Smith wrote: > Roland McGrath wrote: >>> I feel positive I am missing something completely here! >> Oh, wait. We are talking about ia64. So it probably actually can go >> forward and backward in time. We need to get the ia64 kernel people on >> this, for sure. I can see the potential rip in the fabric of spacetime, >> but I don't really understand all the physics involved much at all. The >> corners of this might well differ in RHEL5 vs the vanilla ia64 kernel. > > ... interesting technical discussion deleted ... > > OK, you've convinced me. I'll try to get access to an ia64 machine > again and investigate further. Here's an update. After looking at this more, I decided the systemtap internal code to get syscall arguments was too far off the upstream code. So, I copied the upstream code into systemtap (and have checked this in). The good news is that syscall arguments look much better in general now and I don't see the all args as 0 problem. The bad news is that the utrace_syscall_args test still doesn't pass. The new symptom is that whenever I use "syscall(number, args...)", systemtap sees the syscall number as the 1st argument. Here's an example from a small test program I wrote: fd = dup(2); close(fd); fd = syscall (__NR_dup, 2); close(fd); Logically, these calls should appear to systemtap as identical (as they do to strace). Here's what I get: --------- # stap -ve 'probe process("duptest").syscall {printf("%d(0x%x, 0x%x, 0x%x)\n", $syscall, $arg1, $arg2, $arg3)}' -c ./duptest ... 1057(0x2, 0xff2cd8fe79459316, 0x60000fffff923750) 1029(0x3, 0xff2cd8fe79459316, 0x60000fffff923750) 1057(0x421, 0x2, 0x60000fffff923750) 1029(0x3, 0x2, 0x60000fffff923750) 1236(0x0, 0x3, 0x0) Pass 5: run completed in 21usr/97sys/204real ms. --------- On ia64, dup is 1057. The first dup call above works correctly and sees the 1st argument as 2. The second dup call sees 0x421 as the 1st argument (0x421 is 1057) and 2 as the 2nd argument. The utrace_syscall_args test sees the same problem. When syscall() is used, the arguments are shifted over by 1. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)