From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 489 invoked by alias); 2 Oct 2013 11:24:18 -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 392 invoked by uid 89); 2 Oct 2013 11:24:17 -0000 Received: from mail4.hitachi.co.jp (HELO mail4.hitachi.co.jp) (133.145.228.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2013 11:24:17 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail4.hitachi.co.jp Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 6634C33CC2; Wed, 2 Oct 2013 20:24:13 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id r92BODd3013446; Wed, 2 Oct 2013 20:24:13 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r92BOCn0004468; Wed, 2 Oct 2013 20:24:12 +0900 Received: from gmml27.itg.hitachi.co.jp (unknown [158.213.165.130]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 09D6014003D; Wed, 2 Oct 2013 20:24:12 +0900 (JST) Received: from [10.198.211.143] by gmml27.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id r92BOBw10039528; Wed, 2 Oct 2013 20:24:11 +0900 Message-ID: <524C025B.1060402@hitachi.com> Date: Wed, 02 Oct 2013 11:24:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sandeepa Prabhu Cc: William Cohen , systemtap@sourceware.org, Deepak Saxena Subject: Re: Regarding systemtap support for AArch64 References: <1380011243.3958.11921.camel@bordewijk.wildebeest.org> <52432F3B.4020503@redhat.com> <5248E391.3060306@hitachi.com> <52496A50.9090904@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00001.txt.bz2 (2013/10/02 13:17), Sandeepa Prabhu wrote: > Hi all, > > I have uploaded ARM64 kprobes work on Linaro public git: > git://git.linaro.org/people/sandeepa.prabhu/linux-aarch64.git Branch: > kprobes_devel_v8. Patches are published on LAKML too. This is based > on v8 upstream kernel (3.12-rc1) right now, and works with linaro > boot-wrapper and fast model setup, though, not sure what it takes to > build for fedora. Thank you for the great work! :) At a glance, I have some comments (almost formatting issues) on it. - kprobes def config patch should be moved after the kprobe support. - Is it really need to use spinlock to protect break_hook? Why can't we use rcu_lock as step_hook? - patch_text should check the alignment in itself and return an error. - For ease of bisect debugging, I'd recommend you to split decoder and simulator, and to reorder it as below. 1. decoder patch 2. kprobes basic patch (this doesn't support insns which need simulator) 3. simulator & kprobes enhancement patch - probes-*.c is not good name for the simulator. those should have better name. - kprobes-arm64.c is also not good name. I think we can have arch/arm64/kernel/kprobes/ directory on arm64 as same as x86. we may have core.c and insn_map.c. - probes-common.c looks only for kprobes. This should be go into kprobes.c. - It seems that a part of kretprobe logic is in the kprobes' patch. IMHO, the simulator/decoder will be useful for other cases (KVM, mmiotrace etc.) So I recommend you to keep it away from kprobes as far as possible. And please CC the series to me next time (since I don't subscribe LAKML...). Thank you again! > > Will, > > Is aarch64 fc19 port public? I am interested in using fc on v8 fast > model, are there instructions about how to get the packages and > build/run them? > > Thanks, > Sandeepa > > > > On 30 September 2013 17:40, William Cohen wrote: >> On 09/29/2013 10:36 PM, Masami Hiramatsu wrote: >>> (2013/09/26 12:13), Sandeepa Prabhu wrote: >>>> Hi Will, Masami, >>>> >>>> Nice to hear from you, I am using ARM fast model/Foundation model with >>>> ARM v8 upstream kernel and a Linaro minimal busybox based ramdisk, >>>> testing with loadable modules for now (so don't have dependency on >>>> elfutils or GCC autoconf etc) >>>> >>>> Would you be interested to use Linaro kprobe work as a base for >>>> development and validation of systemtap-aarch64? We are happy to >>>> share a public git repo where 'upstream' kernel can be built with >>>> kprobes support, which systemtap team can use for verification. I can >>>> do this soon as I have most things working locally, except for >>>> kretprobes and 'boosting' support(systemtap can be run without these I >>>> believe). >>> >>> Of course I'm interested in that. Actually I've tried to boot up Linaro's >>> Aarch64 kernel on a simulator which ARM is distributing. >>> As far as I could see (at that time), aarch64 branch already has singlestep >>> implementation for debugging, but no primitive kprobes. And we need to know >>> the aarch64 ISA for decoding the binary to find the instructions which will >>> be affected by the out-of-line execution, like relative jump, call etc. >>> >>>> Looking forward for a collaboration :-) >>> >>> Me too ;) >>> >>> Thanks! >>> >> >> Hi All, >> >> I am still trying to get a better kernel running on the aarch64 simulator. Currently the simulator is running and Fedora 19 image and Linux 3.9+ kernel, but I don't have any of the needed kernel-devel stuff for that kernel. As a work around I am using the aarch64 kernel rpms and attempting to build systemtap instrumentation modules using the following rpms: >> >> kernel-3.12.0-0.rc0.git20.1.x2.fc19.aarch64 >> kernel-devel-3.12.0-0.rc0.git20.1.x2.fc19.aarch64 >> >> These kernel rpms are cross compiled so some script executables are for AMD64 rather than aarch64. I had to go through and recompile the script executables. However, I was able to get an instrumentation modules with the current git checkout for simple hello world: >> >> $ sudo ../install/bin/stap -v -m hello -r 3.12.0-0.rc0.git20.1.x2.fc19.aarch64 -p4 -k -e 'probe begin {printf("hello world\n")}' >> >> Pass 1: parsed user script and 92 library script(s) using 38784virt/30080res/5504shr/23360data kb, in 4730usr/30sys/4763real ms. >> Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 39296virt/32000res/5952shr/23872data kb, in 80usr/0sys/81real ms. >> Pass 3: translated to C into "/tmp/stapzSdKrS/hello_src.c" using 39296virt/32000res/5952shr/23872data kb, in 10usr/0sys/7real ms. >> hello.ko >> Pass 4: compiled C into "hello.ko" in 114710usr/3620sys/120572real ms. >> Keeping temporary directory "/tmp/stapzSdKrS" >> >> There are still other things that need to be fixed in systemtap for aarch64. However, if you are feeling adventurous you might try the current systemtap git checkout on aarch64. >> >> -Will > > -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com