From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32647 invoked by alias); 23 Aug 2007 21:20:41 -0000 Received: (qmail 32345 invoked by uid 22791); 23 Aug 2007 21:20:40 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Aug 2007 21:20:31 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7NLLpBJ010115 for ; Thu, 23 Aug 2007 17:21:51 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7NLKTT2380692 for ; Thu, 23 Aug 2007 17:20:29 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7NLKTlW025233 for ; Thu, 23 Aug 2007 17:20:29 -0400 Received: from [9.47.21.135] (dogbert.beaverton.ibm.com [9.47.21.135]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7NLKSpv025157; Thu, 23 Aug 2007 17:20:29 -0400 Message-ID: <46CDF9DD.9000503@us.ibm.com> Date: Thu, 23 Aug 2007 22:10:00 -0000 From: Dave Nomura Reply-To: dcnltc@us.ibm.com Organization: LTC Power Linux Toolchain User-Agent: Thunderbird 1.5.0.7 (X11/20060911) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: Maynard Johnson , systemtap@sourceware.org, Maynard Johnson , James Keniston Subject: Re: proposed instruction trace support in SystemTap References: <4689826A.9040902@us.ibm.com> <4693CC29.8090700@us.ibm.com> <46C8A82C.1000204@us.ibm.com> In-Reply-To: <46C8A82C.1000204@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2007-q3/txt/msg00426.txt.bz2 From a conversation with Paul Mackerras I recently learned that __debugger_sstep() is the PPC trap handler pointer used only for kernel debugging, and its use is based on only one kernel debugger active at a time. Although I think a kernel API could be created to coordinate use of this function pointer, I don't think one exists. It would probably be prudent to put restrictions on instruction tracing of kernel code in the SystemTap-itrace feature. Although ptrace() probably is not suitable for instruction tracing of user code, if for no other reason that performance issues, I have been looking into some of the documentation of utrace, and am wondering if it might be suitable. I Dave Nomura wrote: > I've been looking into the kernel API for handling single stepping and > haven't really found anything. ptrace() is used by gdb but it's usage > model might be overly restrictive for what we want: we would have to > have a parent process then uses ptrace() to trace it's children. > ptrace() also does not trace into the kernel which is an ITRACE > requirement. > > I think the requirement of tracing into the kernel is only needed in > some scenarios and may only be needed for the ITRACE application of > SystemTap instruction tracing. In its most general form Perfomance > Inspector ITRACE allows tracing into the kernel and tracing of a whole > range of processes. Due to these requirements it places usage > constraints on the user that requires exclusive access ot a machine. > In the more common SystemTap instruction tracing scenario only a > single process is being traced, and only user code is traced maybe it > would be approriate to use ptrace() to do the single stepping. > > It has already been suggested that we have different APIs for ITRACE > vs. simpler (non-kernel tracing) instruction tracing modes so it might > be a simple matter of telling the SystemTap translator what kind of > trap handler to generate (or referencd from the runtime stap > scripts). In the non-kernel-tracing-single-process scenario just the > normal process switch management of registers will handle restoring > the single step trap bit, or if ptrace() (or possibly utrace()). > > The ITRACE-kernel-tracing scenario might require similar usage > restrictions as PI ITRACE, and we simply would require that you aren't > using other kernel debuggers (xmon, kgdb,...) while trying to do an > ITRACE to avoid conflict over the kernel resources needed for > instruction tracing. Alternatively, a kernel API (if it doesn't > already exist) for handling these kernel resources could be created. > I have heard that xmon and kgdb both use the __debugger_sstep() trap > handler pointer. > Frank Ch. Eigler wrote: >> >>> [...] There is basically one single instruction trap handler that >>> the stap translator will generate with logic to figure out what >>> handler code to run [...] >>> >> >> The "existing kernel API" is the key issue here. How exactly does one >> activate single-stepping traps on each of the interesting >> architectures, and on multiple different kernel generations (RHEL)? >> How does one hook into the handling system correctly (avoiding >> interference to other consumers of trap data like gdb, uprobes)? >> >> These questions need answers in order for systemtap to generate code >> to implement this. >> >> >> - FChE >> >> > >