From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4220 invoked by alias); 16 Nov 2007 21:51:07 -0000 Received: (qmail 4211 invoked by uid 22791); 16 Nov 2007 21:51:07 -0000 X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e4.ny.us.ibm.com (HELO e4.ny.us.ibm.com) (32.97.182.144) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Nov 2007 21:51:05 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lAGLp3HV024633 for ; Fri, 16 Nov 2007 16:51:03 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lAGLp3B9136430 for ; Fri, 16 Nov 2007 16:51:03 -0500 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 lAGLp3rL023354 for ; Fri, 16 Nov 2007 16:51:03 -0500 Received: from [9.47.18.96] (dyn9047018096.beaverton.ibm.com [9.47.18.96]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lAGLp2Yr023309; Fri, 16 Nov 2007 16:51:02 -0500 Subject: Re: user instruction tracing patch? From: Jim Keniston To: "Frank Ch. Eigler" Cc: systemtap@sourceware.org In-Reply-To: <20071116212420.GE25326@redhat.com> References: <20071114231540.GD32440@redhat.com> <20071114233825.068D326F8B6@magilla.localdomain> <20071115035803.GE32440@redhat.com> <1195175032.3804.163.camel@dyn9047018096.beaverton.ibm.com> <1195241772.3965.42.camel@dyn9047018096.beaverton.ibm.com> <20071116192034.GA25326@redhat.com> <1195248052.3965.66.camel@dyn9047018096.beaverton.ibm.com> <20071116203708.GC25326@redhat.com> <1195247268.8520.4.camel@dyn9047018096.beaverton.ibm.com> <20071116212420.GE25326@redhat.com> Content-Type: text/plain Date: Fri, 16 Nov 2007 21:51:00 -0000 Message-Id: <1195249801.8520.13.camel@dyn9047018096.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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-q4/txt/msg00363.txt.bz2 On Fri, 2007-11-16 at 16:24 -0500, Frank Ch. Eigler wrote: > Hi - > > On Fri, Nov 16, 2007 at 01:07:47PM -0800, Jim Keniston wrote: > > [...] > > Sorry, I still don't get it then. Given > > probe program("/bin/vi").function("malloc") if (mp) { .. } > > if some handler executes > > mp = 1; > > how does stap know which instance(s) of vi to probe? > > None of this exists yet, but it should work similarly to kprobes > where lack of probe point qualification means "all of them". So > > probe program("/bin/vi").function("malloc") { } > > would be a request to probe all running (and forseeably, any future) > copies of vi. To filter further, I imagine additional qualifiers such > as ".pid(NUM)", ".uid(NUM)". These are all to identify the potential > probing target processes. In the above examples, if NUM could be a variable name, then I think we're in business... especially if it could be a set of pids or uids (implemented as, or perhaps explicitly, an associative array?). (I can always dream...) > The conditional enable/disable stuff is intended to be orthogonal. > They do not create or destroy probing targets/opportunities, merely > turn them on or off. > > - FChE Jim