From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32052 invoked by alias); 16 Mar 2009 05:20:57 -0000 Received: (qmail 32043 invoked by uid 22791); 16 Mar 2009 05:20:56 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_50,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Mar 2009 05:20:51 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2G5IAw7024984 for ; Sun, 15 Mar 2009 23:18:10 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2G5Kn6i195896 for ; Sun, 15 Mar 2009 23:20:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2G5Kmhh002781 for ; Sun, 15 Mar 2009 23:20:48 -0600 Received: from thinktux.in.ibm.com (thinktux.in.ibm.com [9.124.31.33]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2G5KlHL002749; Sun, 15 Mar 2009 23:20:48 -0600 Received: by thinktux.in.ibm.com (Postfix, from userid 500) id 6065126107; Mon, 16 Mar 2009 10:50:54 +0530 (IST) Date: Mon, 16 Mar 2009 07:01:00 -0000 From: Ananth N Mavinakayanahalli To: Josh Stone Cc: "Frank Ch. Eigler" , Prerna Saxena , systemtap@sourceware.org Subject: Re: [RFC][PATCH 1/4] kprobe-based symbol resolution for stap-translator Message-ID: <20090316052054.GC3917@in.ibm.com> Reply-To: ananth@in.ibm.com References: <49BA38DB.1080604@linux.vnet.ibm.com> <20090313135005.GB3917@in.ibm.com> <20090313192423.GC16297@redhat.com> <49BACA2C.1050108@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BACA2C.1050108@redhat.com> 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: 2009-q1/txt/msg00719.txt.bz2 On Fri, Mar 13, 2009 at 02:03:40PM -0700, Josh Stone wrote: > Frank Ch. Eigler wrote: >> - and then some new intelligence in the translator that automatically >> downgrades "kernel.function("...")' probes to 'kernel.kprobe("...")' >> if the probe point & handler does not appear to require debuginfo > > This downgrade could only occur for .call variants, right? A plain > 'kernel.function("...")' could exist as both a standalone function and as > an inline instance if gcc is being clever... Yes, kallsyms_lookup_name() works only with .call. It can and will return only one address per symbol; it won't even resolve compiler inlined instances (many of the signal tapset failures are a result of such inlining). > I'm leery even of this though, because it seems there's no way to validate > the function name until you actually run it, right? I think that fear is an unfounded; as mentioned before, if there are namespace clashes, the first 'found' instance is what gets returned. Sure, there can be bugs in the kallsyms' function name resolution. That'd be a kernel bug and can be fixed. Ananth