From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6182 invoked by alias); 24 Feb 2012 21:49:35 -0000 Received: (qmail 6146 invoked by uid 22791); 24 Feb 2012 21:49:34 -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; Fri, 24 Feb 2012 21:49:18 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1OLnIkH026933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Feb 2012 16:49:18 -0500 Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q1OLnHiT031956; Fri, 24 Feb 2012 16:49:18 -0500 Message-ID: <4F4805DD.9060206@redhat.com> Date: Fri, 24 Feb 2012 21:49:00 -0000 From: William Cohen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120215 Red Hat/3.1.18-2.el6_2 Thunderbird/3.1.18 MIME-Version: 1.0 To: David Smith CC: systemtap@sourceware.org Subject: Re: Recent review of SystemTap test results on ARM running Fedora 15 hard float. 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> In-Reply-To: <4F47E4AF.1010205@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: 2012-q1/txt/msg00196.txt.bz2 On 02/24/2012 02:27 PM, David Smith wrote: > On 02/24/2012 12:26 PM, William Cohen wrote: > >> On 02/24/2012 11:03 AM, David Smith wrote: >>> On 02/23/2012 04:55 PM, David Smith wrote: >>> >>>> On 02/23/2012 04:06 PM, William Cohen wrote: >>>> >>>>> On 02/23/2012 03:54 PM, David Smith wrote: >>>>>> On 02/23/2012 01:06 PM, William Cohen wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for the comments/questions. >>>>> >>>>>> >>>>>>> I reviewed the SystemTap testsuite failures for Fedora 15 hard float running on ARM. You can see the recent ARM test results in dejazilla at: >>>>>>> >>>>>>> http://web.elastic.org/~dejazilla/viewsummary.php?_offset=0&_limit=40&_sort=1A&summary=&age=&rg=&tool=&variant=%3D%27armv7l-unknown-linux-gnu%27&versions=&pass=&fail=&kpass=&kfail=&xpass=&xfail=&untested=&unresolved=&unsupported=&warning=&error= >>>>>> >>>>>> >>> >>> >>>>>>> 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. Here's the > source of uaddr(): > > function uaddr:long() > %{ /* pure */ /* myproc-unprivileged */ > struct pt_regs *uregs; > > > if (CONTEXT->probe_flags & _STP_PROBE_STATE_USER_MODE) > uregs = CONTEXT->uregs; > else > uregs = _stp_current_pt_regs(); > > if (uregs) > THIS->__retvalue = (int64_t) REG_IP(uregs); > else > THIS->__retvalue = 0; > %} > > There are basically 3 possibilities of error here: > > 1) We're getting a bad uregs pointer from the context structure > 2) We're getting a bad uregs pointer from the _stp_current_pt_regs(). > 3) REG_IP() isn't interpreting the good uregs pointer correctly > > If you want to track this down further, first try to figure out where > we're getting uregs from. It should be doing this code in kernel-space. Printed valude of user_mode() to verify. Ruled out #1. It is getting information from _stp_current_pt_regs(). I started taking a look at the uaddr() and umodname() code to see where they are getting things. See where REG_IP() coming from for arm, runtime/regs.h: #elif defined (__arm__) #define REG_IP(regs) regs->ARM_pc #define REG_SP(regs) regs->ARM_sp #define REG_LINK(regs) regs->ARM_lr See ARM_pc defined in: http://lxr.linux.no/#linux+v3.2.7/arch/arm/include/asm/ptrace.h#L114 I will do some more looking around why this doesn't work this evening. -Will