From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4364 invoked by alias); 6 Feb 2008 08:12:27 -0000 Received: (qmail 4355 invoked by uid 22791); 6 Feb 2008 08:12:26 -0000 X-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_20 X-Spam-Check-By: sourceware.org Received: from E23SMTP05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.18.174) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Feb 2008 08:12:00 +0000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.18.234]) by e23smtp05.au.ibm.com (8.13.1/8.13.1) with ESMTP id m168Bi8d000709 for ; Wed, 6 Feb 2008 19:11:44 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m168BuZD3596374 for ; Wed, 6 Feb 2008 19:11:56 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m168Bwf7005564 for ; Wed, 6 Feb 2008 19:11:58 +1100 Received: from localhost.localdomain (prasadkr-t60p.in.ibm.com [9.124.31.44]) by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m168BuKD005490; Wed, 6 Feb 2008 19:11:57 +1100 Date: Wed, 06 Feb 2008 08:12:00 -0000 To: "David Smith" , "Systemtap List" Subject: Re: New kernel marker wiki page Reply-To: prasad@linux.vnet.ibm.com From: "K.Prasad" Organization: IBM Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 References: <478B88EF.1010003@redhat.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <478B88EF.1010003@redhat.com> User-Agent: Opera Mail/9.24 (Linux) 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: 2008-q1/txt/msg00219.txt.bz2 Hi David and all, Thanks for posting the wiki. I thought I would bring the issue of handling structure pointers in SystemTap script for the members to deliberate upon. Quoting the wiki here to bring the context: "How are marker arguments handled that are structure pointers? Not well. Because systemtap has no DWARF information for marker arguments, it really doesn't know what type they are. In a DWARF-based probe, you could write something like this: probe kernel.function("kfunc") { printf("inode number: %d\n", i->i_ino) } However, if you try something similar with a marker-based probe, you'll get an error because systemtap doesn't know that: * $arg1 is a pointer * the type of what $arg1 points to" Solutions to this problem, as detailed in the wiki, and their shortcomings as I see are: * Solution proposed - "Use Guru mode (-g option) to embed C code that type-casts the datatype to the requisite format" - It would be less desirable to clutter the scripts with embedded C code, and would potentially take away the 'abstraction' and security that these SystemTap scripts are expected to provide. * Solution proposed - "go ahead and put the interesting structure fields in the marker itself" - From the previous discussions related to marker patches (submitted for RCU debugging infrastructure), it was apparent that the community desired the least amount of instrumentation code in the kernel. This would be more pronounced when markers are proposed in critical code regions which would have in the performance of the system. In such cases we may have to export the parent data structure (which will enable us to extract all the data-members of the structure of interest, in the marker handler/SystemTap script). Say, if we have a structure struct X { a, b, c,.....z} and if we are interested in only a few members (although not all), it would still be worthwhile to embed the instance of 'struct X' in the trace_mark() - to optimise the marker for a not-taken case. * The other method would be to make a similar declaration of the data structure and use them. But again, this comes with costs such as - bloating of SystemTap scripts, added complexity and maintenance overhead (keep the data type of the parameters in the script in sync with the kernel). Given these usability issues for SystemTap over markers in the absence of DWARF information, would it still be a good idea to exclude DWARF information or are there other plans to mitigate them? Thanks, K.Prasad On Mon, 14 Jan 2008 21:38:15 +0530, David Smith wrote: > I've gotten requests for more kernel marker information, so I decided to > summarize what I know on a new wiki page: > > > > (It was a useful exercise, since I discovered bug 5608 while writing the > page.) > > If you see any additional areas (or have additional questions) that need > covering send me an email or add the info yourself. > > I hope this helps. >