From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28580 invoked by alias); 14 Jun 2006 22:42:09 -0000 Received: (qmail 28573 invoked by uid 22791); 14 Jun 2006 22:42:09 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Jun 2006 22:42:01 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5EMg0jo013006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Jun 2006 18:42:00 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5EMfkPv244234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jun 2006 16:41:46 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5EMfx24013471 for ; Wed, 14 Jun 2006 16:41:59 -0600 Received: from [127.0.0.1] (IBM-BE3QP6HK0F9.beaverton.ibm.com [9.47.16.136]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5EMfwFF013426; Wed, 14 Jun 2006 16:41:59 -0600 Message-ID: <449090B5.5080007@us.ibm.com> Date: Wed, 14 Jun 2006 22:42:00 -0000 From: Vara Prasad User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: systemtap@sources.redhat.com Subject: Re: user-space probes -- plan B from outer space References: <44862DF2.3000402@us.ibm.com> In-Reply-To: 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-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00625.txt.bz2 Frank Ch. Eigler wrote: >prasadav wrote: > > > >>[...] Well another approach is similar to Ptrace actions you have >>predefined handlers that some one can activate through a new >>systemcall. [...] >> >> > >A fixed pool of predefined handlers seem like an antithesis of >systemtap. Did you have some user interface in mind for these? > > Like i mentioned in response to Prasanna's user space probes approach mail there will be two types of handlers for user space probes. One type is predefined for specific tasks like dump the stack, get registers etc., these handlers are built into the kernel. The second type of handlers are the ones that can be added on demand using a module load and register them similar to kprobes. SystemTap will use the second approach. Association of a break point to handler is done as a separate step and either type of the handlers can be associated with the breakpoint. The idea of predefined handlers is if you don't want to write any complicated handlers and probe only your own process you could use the preexisting handlers and don't need to write kernel module and possibly don't even need root permission to trace. This addresses one of the comments we got for earlier userspace implementation posting in LKML. > > >>> user.process(233).statement(0xfeedface) >>> user("fche").process("/bin/vi").function("*init*") >>> >>> >>In my opinion user space probes is most useful in the case of server >>class kind of complicated programs which are usually long living, >>[...] there is not much value with system wide tracing instead we >>should focus on process specific tracing. [...] >> >> > >There is no contradiction here. System-wide probing can be >accomplished by a collection of process-specific probes. > > > >>[...] I am not sure i see the value of process("process name") >>syntax if our focus is process specific tracing. >> >> > >It would be one way of identifying present or future processes to >probe. For processes that do not yet exist, what other scheme do you >have in mind? > > The scheme i am thinking is you could start a new process using systemtap, systemtap will then fork a copy of itself and exec the new executable on the child. This gives systemtap ability to put probes on the child process from the start similar to what gdb does if you start a program under debugger. With the ability to probe already running process and as well as able to start new process under systemtap we can probe most applications. The one case that we can not cover with the above two is if an application has a complicated startup. For example if script A starts Script B and script B starts an executable C and executable C is a short lived one, since C is a short lived one it will not give us a chance to put probes before it exits. I think these kinds of cases are not too many to worry for now at least. Do you think of any other useful cases that we need to probe not covered by the above two approaches? > > >>I am not sure i see lot of value of this solution compared to a gdb >>batch job, but for bit better performance than the heavy weight gdb. >>[...] >> >> > >How would this gdb batch job alternative work? Are you intending to >compare the expressity of systemtap script with gdb macros? > > > I am not saying gdb macros are as powerful as systemtap scripts. All i meant is one can use gdb batch scripts to print the variables you need and use all kinds of post processing using your favorite scripting language. As the handlers are run in the userspace i am not seeing much advantage of using systemtap language to do filtering in the userspace vs post processing using your favorite scripting language. [...] > >- FChE > >