From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12481 invoked by alias); 18 Sep 2008 16:11:29 -0000 Received: (qmail 12466 invoked by uid 22791); 18 Sep 2008 16:11:28 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Sep 2008 16:10:43 +0000 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8IGAfHv007025 for ; Thu, 18 Sep 2008 12:10:41 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8IGAawm114388 for ; Thu, 18 Sep 2008 10:10:38 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8IGAX8d018474 for ; Thu, 18 Sep 2008 10:10:33 -0600 Received: from thinktux.in.ibm.com ([9.77.207.154]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8IGAVu8017976; Thu, 18 Sep 2008 10:10:32 -0600 Received: by thinktux.in.ibm.com (Postfix, from userid 500) id 153AA26B2D; Thu, 18 Sep 2008 21:40:42 +0530 (IST) Date: Thu, 18 Sep 2008 16:11:00 -0000 From: Ananth N Mavinakayanahalli To: Theodore Tso Cc: "R. J. Moore" , systemtap@sources.redhat.com Subject: Re: kernel summit session on systemtap Message-ID: <20080918161041.GA3643@in.ibm.com> Reply-To: ananth@in.ibm.com References: <48D20A8F.4060307@uk.ibm.com> <20080918154629.GD9640@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080918154629.GD9640@mit.edu> User-Agent: Mutt/1.5.16 (2007-06-09) 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-q3/txt/msg00701.txt.bz2 On Thu, Sep 18, 2008 at 11:46:29AM -0400, Theodore Tso wrote: > On Thu, Sep 18, 2008 at 09:00:15AM +0100, R. J. Moore wrote: > > I don't know whether it is possible with the latest code, but for > > debugging purposes, I would be happy if SystemTap could operate on > > external names and relative addresses - i.e. without the need to have > > any symbolic information. > > You can certainly set tracepoints that way. I don't know how easy it > would be to fetch out register information or interpret complex data > structures living on the stack or in function parameters without debug > information, though. Usually if I have to do that level of analysis, > at least at this point it's faster for me to rebuild without debuginfo > information, drop the use of system tap, and retreat to printk > debugging. Or you could use just vanilla kprobes. Kprobes allows for users to specify a symbol name string (kp.symbol_name) and an offset (kp.offset) and the probe is inserted at that exact location. No printks and no requirement for debuginfo :-) ... > (By the way, is testing to make sure all > of the tapsets in the tree to make sure they work still turned off > because so many of them are still broken? That was few months ago > when someone on the list told me that, but that was another face-palm > moment for me.) There are some probe points in tapsets (eg., the signal tapset) which used certain function probes, which later got inlined due to compiler optimizations. Such tests do fail. A panacea for such cases is to migrate to a kernel marker based mechanism. Ananth