From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6289 invoked by alias); 28 Apr 2009 14:54:52 -0000 Received: (qmail 6281 invoked by uid 22791); 28 Apr 2009 14:54:50 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43,J_CHICKENPOX_71,J_CHICKENPOX_73,J_CHICKENPOX_91,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.43rc1) with ESMTP; Tue, 28 Apr 2009 14:54:44 +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.8) with ESMTP id n3SEsgLh013860 for ; Tue, 28 Apr 2009 10:54:42 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3SEsgHW020101 for ; Tue, 28 Apr 2009 10:54:42 -0400 Received: from multics.rdu.redhat.com (multics.rdu.redhat.com [10.11.228.43]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3SEsfkV028015 for ; Tue, 28 Apr 2009 10:54:41 -0400 Message-ID: <49F718B1.40406@redhat.com> Date: Tue, 28 Apr 2009 14:54:00 -0000 From: Stan Cox User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: SystemTap List Subject: alternate static marker approach 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: 2009-q2/txt/msg00456.txt.bz2 We have been thinking about alternative static marker approaches. Perhaps the @cast support might provide an alternative to the clever, or baroque depending on one's perspective, macros used to set up the markers. The dtrace .d input file types are self contained so if a .d file was converted to a .h file and made available in a place like /usr/share then it would be easy for @cast to make use of it. For the purpose of the example the dup syscall has been hijacked as a means of setting the probe. So given this little example: * tstsyscall.h * // this would be created from package.d struct astruct { int a; int b; }; * tstsyscall.c * #define _GNU_SOURCE #include #include "tstsyscall.h" int main(int argc, char *argv[]) { int ret; int a1 = 1; int a2 = 2; int a3 = 3; int a4 = 4; struct astruct astruct = {5, 6}; // STAP_PROBE(test,probe_one,a1,a2,a3,a4,&astruct) would map to: ret = syscall (__NR_dup, -12345, a1, a2, a3, a4, &astruct); } So a probe like: stap -c ./tstsyscall.x -e 'probe process("tstsyscall.x").mark("test") { printf("a2=%d a3=%d a4=%d a5=%d astruct.a=%d astruct.b=%d\n", a1, a2, a3, a4, astruct.a, astruct.b)' could map to something like: stap -c ./tstsyscall.x -e ' probe syscall.dup { arg2=int_arg(2);arg3=int_arg(3);arg4=int_arg(4);arg5=int_arg(5); arg6a=@cast(ulong_arg(6),"astruct","")->a; arg6b=@cast(ulong_arg(6),"astruct","")->b; printf("a1=%d a2=%d a3=%d a4=%d astruct.a=%d astruct.b=%d\n",name, arg1,arg2,arg3,arg4,arg5,arg6a,arg6b)}' which yields: a1=1 a2=2 a3=3 a4=4 astruct.a=5 astruct.b=6 For example here is an excerpt from tclDTrace.d typedef struct Tcl_Obj Tcl_Obj; provider tcl { probe proc__entry(char* name, int objc, Tcl_Obj **objv); ... } struct Tcl_Obj { int refCount; char *bytes; int length; ... }