From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29011 invoked by alias); 25 Feb 2012 19:40:04 -0000 Received: (qmail 28991 invoked by uid 22791); 25 Feb 2012 19:40:03 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 25 Feb 2012 19:39:42 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1PJdfkf014301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 25 Feb 2012 14:39:41 -0500 Received: from toonder.wildebeest.org (ovpn-116-30.ams2.redhat.com [10.36.116.30]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1PJdeFC001346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Feb 2012 14:39:41 -0500 Received: by toonder.wildebeest.org (Postfix, from userid 1000) id 9C529204C2; Sat, 25 Feb 2012 20:39:39 +0100 (CET) Date: Sat, 25 Feb 2012 19:40:00 -0000 From: Mark Wielaard To: David Smith Cc: William Cohen , systemtap@sourceware.org Subject: Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float. Message-ID: <20120225193939.GA32752@toonder.wildebeest.org> References: <4F468E22.4010308@redhat.com> <4F46A795.8000307@redhat.com> <4F46B861.5060201@redhat.com> <4F46C3F8.7080900@redhat.com> <4F47B4E4.2080803@redhat.com> <4F47D662.9000509@redhat.com> <4F47E4AF.1010205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F47E4AF.1010205@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-q1/txt/msg00199.txt.bz2 On Fri, Feb 24, 2012 at 01:27:43PM -0600, David Smith wrote: > On 02/24/2012 12:26 PM, William Cohen wrote: > >>>>>> FAIL: vma_vdsodefault > >>>>>> vma_vdso.stp uses uaddr() which didn't work on arm. > >>>>> > >>>>> Hmm, can you tell in systemtap.log what part of 'uaddr()' didn't work? > >>>> > >>>> The log wasn't too helpful. When running the test by hand. Looks like umodename(uaddrr()) == "", so getting from > >>>> > >>>> printf("%s@%x unknown\n", name, uaddr()); > >>> > >>> Hmm, I'll try looking at this one some more. > >> > >> The first thing we need to do here is figure out which is really > >> failing, uaddr() or umodname(). Could you change the test to just print > >> out the return value of uaddr() to see what it is returning? > > > > Added the following to the vma_vdso.stp just inside the (target() == pid()) > > > > + printf("%s umodname(uaddr()) = umodname(%x) = %s\n", > > + name, uaddr(), umodname(uaddr())); > > > > > > $ ../install/bin/stap ../systemtap/testsuite/systemtap.base/vma_vdso.stp -c testsuite/vma_vdsodefault.exe > > clock_gettime umodname(uaddr()) = umodname(401096ec) = > > clock_gettime@401096ec unknown > > getuid umodname(uaddr()) = umodname(40254e10) = > > getuid@40254e10 unknown > > getuid umodname(uaddr()) = umodname(40221f5c) = > > getuid@40221f5c unknown > > > > Below is the maps for the process to see where those addresses would map. The results of uaddr() do not look correct. > > > ... > > Interesting. So we got an address, but not a good address. Note that this test explicitly tries to test an address has an known module name, even if it is in the vdso, which is normally randomly allocated in the process address space. In the vma_vdso.c test program we see it uses a trick to make sure we end up in the vdso (this depends on the implementation of clock_gettime on the platform, so make sure on ARM this also results into actually going into the vdso). /* Give an invalid clockid_t on purpose so the vdso has to call through to the kernel syscall. */ The testcase also tests the testuid call in two different ways. Maye that is an easier case on ARM? Then in vma_vdso.stp we see that the probes are in kernel space: probe syscall.clock_gettime, syscall.getuid It would surprise me if the uaddr() was really wrong, but it could be. I suspect that the uaddr() is in the vdso and the vdso tracker is broken on ARM. A simpler test would be running this: stap -e 'probe syscall.clock_gettime, syscall.getuidr { if (pid() == target()) printf("%s 0x%x in %s\n", name, uaddr(), umodname(uaddr())) }' \ -c testsuite/vma_vdso-m64.exe Which on x86_64 gives: clock_gettime 0x7fff689ff9cf in vdso getuid 0x3c5c0ed819 in /usr/lib64/libc-2.15.so getuid 0x3c5c0bb007 in /usr/lib64/libc-2.15.so Does that fail for all invocations on ARM? If it is the vdso tracker then you want to take a look at runtime/vma.c _stp_vma_match_vdso will give some debug output with stap -DDEBUG_TASK_FINDER_VMA Cheers, Mark