From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18150 invoked by alias); 7 Nov 2013 14:56:33 -0000 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 Received: (qmail 18141 invoked by uid 89); 7 Nov 2013 14:56:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPAM_SUBJECT,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Nov 2013 14:56:31 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA7EuKob019449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 09:56:21 -0500 Received: from [10.13.129.31] (dhcp129-31.rdu.redhat.com [10.13.129.31]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA7EuJM2022893; Thu, 7 Nov 2013 09:56:19 -0500 Message-ID: <527BAA13.4000301@redhat.com> Date: Thu, 07 Nov 2013 14:56:00 -0000 From: William Cohen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Sandeepa Prabhu , Petr Machata CC: Mark Wielaard , Masami Hiramatsu , systemtap@sourceware.org, Deepak Saxena , Krishna Dani , Jakub Pavelek , Mark Salter Subject: Re: [Fwd: Re: Regarding systemtap support for AArch64] References: <1383340682.3850.864.camel@bordewijk.wildebeest.org> <5277FBF2.2080108@redhat.com> <52791818.9070809@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00180.txt.bz2 On 11/07/2013 06:54 AM, Sandeepa Prabhu wrote: > On 6 November 2013 15:24, Petr Machata wrote: >> William Cohen writes: >> >>> On 11/04/2013 09:48 PM, Petr Machata wrote: >>>> That 0x3F in x8 might be __NR_read, that might be from the syscall that >>>> got us here. So possibly makes sense. 0x112 is __NR_syscalls, I don't >>>> see how that ended up there. Maybe from a conditional? 0x2004 might >>>> certainly be a length, though it's an odd one. The two kernel-space >>>> parameters have similar values, and the one user-space is quite >>>> different--again, makes sense. >>> >>> These examples systemtap might not be the best. It is just printing >>> information for the first vfs.read or vfs.read.return encountered, so >> >> I understand. I was trying to figue out what's in the registers. I can >> agree that x0 to x4 hold vfs_read arguments on entry, so why doesn't, on >> function return, x0 hold the return value? >> >>> I wonder if there might be some issue with the patches implementing >>> the arm64 kprobes support and that the registers are not be saved >>> properly. >> >> I was wondering about the same thing. > Hi Will, Petr, > > Yes, I found some design issue with respect to trampoline placement, > (my code is the culprit!!). I am going to fix this soon and update you > all. > > Thanks, > Sandeepa >> >> Thanks, >> PM Hi Sandeepa, I was just going to ask you about the trampoline code. I ran a little experiment and it looked like the place the probe was firing wasn't correct. $ sudo ~/systemtap_write/install/bin/stap -k -v -e 'probe vfs.read.return {printf("$return = 0x%x\n", $return);print_regs(); exit()}' [sudo] password for wcohen: Pass 1: parsed user script and 93 library script(s) using 140720virt/25044res/2776shr/22936data kb, in 4740usr/190sys/5353real ms. Pass 2: analyzed script: 2 probe(s), 8 function(s), 6 embed(s), 0 global(s) using 323612virt/103604res/3656shr/100456data kb, in 39780usr/13630sys/58215real ms. Pass 3: translated to C into "/tmp/stap0GjZue/stap_1107_src.c" using 323612virt/105948res/6000shr/100456data kb, in 150usr/10sys/176real ms. Pass 4: compiled C into "stap_1107.ko" in 119270usr/10570sys/143518real ms. Pass 5: starting run. $return = 0xffffffc04609f700 pc : [] lr : [] pstate: 60000145 sp : ffffffc04ce8be30 x29: ffffffc04ce8be80 x28: ffffffc04ce88000 x27: ffffffc000835000 x26: 000000000000003f x25: 0000000000000112 x24: 0000000000000015 x23: 0000000080000000 x22: 0000007f7a332aa8 x21: 0000000000000001 x20: 0000007fd0e51730 x19: ffffffc04609f700 x18: 0000007fd0e4f250 x17: 0000007f7a332a50 x16: ffffffc0001868e0 x15: 0000000000000004 x14: 0000007fd0e53a70 x13: 0000000000000001 x12: 0000000000000000 x11: 0000007fd0e4f530 x10: 0000000000401277 x9 : 0000000000000028 x8 : 000000000000003f x7 : 0000000000000005 x6 : 0000000000000000 x5 : 0000000000000002 x4 : 0000000000000000 x3 : ffffffc04ce8beb0 x2 : 0000000000002004 x1 : 0000007fd0e51730 x0 : ffffffc04609f700 Pass 5: run completed in 120usr/80sys/579real ms. Keeping temporary directory "/tmp/stap0GjZue" [wcohen@localhost systemtap]$ Look at pc : [] ffffffc000186130 : ffffffc000186130: a9bb7bfd stp x29, x30, [sp,#-80]! ffffffc000186134: 910003fd mov x29, sp ffffffc000186138: a9025bf5 stp x21, x22, [sp,#32] ffffffc00018613c: a90153f3 stp x19, x20, [sp,#16] Look at lr : [] ffffffc00018691c: f9001ba4 str x4, [x29,#48] ffffffc000186920: 97fffe04 bl ffffffc000186130 ffffffc000186924: aa0003f4 mov x20, x0 The lr value look plausible, but the pc value looks like the function entry not the function exit. -Will