From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26231 invoked by alias); 16 Nov 2007 17:18:06 -0000 Received: (qmail 26213 invoked by uid 22791); 16 Nov 2007 17:18:05 -0000 X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_05,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Nov 2007 17:17:57 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lAGHHuTn021999; Fri, 16 Nov 2007 12:17:56 -0500 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAGHHtLt019547; Fri, 16 Nov 2007 12:17:55 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAGHHVFP023549; Fri, 16 Nov 2007 12:17:47 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id A1C618001FF; Fri, 16 Nov 2007 12:17:14 -0500 (EST) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id lAGHGwLU030968; Fri, 16 Nov 2007 12:16:58 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id lAGHGnb2030967; Fri, 16 Nov 2007 12:16:49 -0500 X-Authentication-Warning: ton.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Jim Keniston Cc: Roland McGrath , dcnltc@us.ibm.com, systemtap@sourceware.org Subject: Re: user instruction tracing patch? References: <4739E5C2.80206@us.ibm.com> <20071114215940.5A0DB26F8B6@magilla.localdomain> <20071114231540.GD32440@redhat.com> <20071114233825.068D326F8B6@magilla.localdomain> <20071115035803.GE32440@redhat.com> <1195175032.3804.163.camel@dyn9047018096.beaverton.ibm.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 16 Nov 2007 17:18:00 -0000 In-Reply-To: <1195175032.3804.163.camel@dyn9047018096.beaverton.ibm.com> (Jim Keniston's message of "Thu, 15 Nov 2007 17:03:52 -0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00347.txt.bz2 jkenisto wrote: > [...] For example, will stap provide access to all the > task-lifetime events that utrace reports (on a per-task basis, BTW) > -- fork/clone, exec, exit, signal, syscall, etc? I hope so. These sound sensible. It could be interesting to use utrace's system call interception facilities instead of the system-wide ones we were discussing yesterday, when the focus can be appropriately restricted. >[...] > But wouldn't real-life scripts be just as likely to do something like > probe program("PATHNAME").pid(TBD).function("NAME") { ... } > [...] > probe program("PATHNAME").descendent_of($1 /*pid*/).function("NAME") One can get carried away with encoding too much in the probe point syntax. Generally, they are meant to be statically resolvable sorts of things identifying the parts of the system possibly being affected by probing. I'd like to add dynamic things only tastefully - if they are common, compact, obvious; if translator/runtime automation significantly assists performance or safety; if they cannot be reasonably coded up in plain script code. > The above suggests (to me, anyway) that we should either: > 1) support probe enablement via a statement in a probe handler [...] > 2) expand the probe statement syntax to accommodate same. You may be mixing things up. The two alternate syntaxes for on-the-fly probe enable/disable operations are roughly equally capable in this regard. (If it takes script code to determine enablement, then that script code could just as easily use either activating variables or function calls.) - FChE