From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7278 invoked by alias); 21 Dec 2008 00:39:10 -0000 Received: (qmail 7271 invoked by uid 22791); 21 Dec 2008 00:39:09 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_40,FAKE_REPLY_C,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_40,FAKE_REPLY_C,KAM_MX,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; Sun, 21 Dec 2008 00:38:34 +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 mBL0cWG5028438 for ; Sat, 20 Dec 2008 19:38:32 -0500 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 mBL0cWwt019415 for ; Sat, 20 Dec 2008 19:38:32 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBL0cVtO016231 for ; Sat, 20 Dec 2008 19:38:31 -0500 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 mBL0cVtf004176 for ; Sat, 20 Dec 2008 19:38:31 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id mBL0cVnq004175 for systemtap@sources.redhat.com; Sat, 20 Dec 2008 19:38:31 -0500 Date: Mon, 22 Dec 2008 18:22:00 -0000 From: "Frank Ch. Eigler" To: systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium Message-ID: <20081221003831.GG24081@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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-q4/txt/msg00622.txt.bz2 Hi - On Fri, Dec 19, 2008 at 03:50:58PM +0000, Richard J Moore wrote: > [...] I still think there's a case to make ST only weakly dependent > on debuginfo. The original dprobes would use the public names in > the ELF headers to resolve symbols and only resort to debuginfo if > needed. It turns it's needed rather a lot. :-( Without it, we have no typing information with which pointer/struct values can be intelligently processed. We also don't have location information to *find* data such as parameters and locals. It is also our current solution for prologue analysis, so we know where to insert probes on plain (non-regparms) functions compiled by current gcc (where location list data can be simply wrong). Some of this has been predicated on the belief that debuginfo quality will improve enough that we do not need to resort to hard-coded per-architecture per-compiler hacks like some in gdb. > [...] Would could build some scripts with the binaries where debug > info is available, interpret that info as relative offsets to public > symbols then dispense with the info on the shipped production > script. See where I'm going here? It sounds like an interesting sort of shortcut - one that we have not seriously considered. It may be far too optimistic, considering the degree of configuration/optimization change possible between two similar kernel builds, and the prevalent hostility toward reusable kernel modules. > And even for one-off scripts, this is still useful. I have on many > occasions started with a dump, found the information I need > extracting with a dynamic tracepoint and developed the script in > terms relative to public symbols. No debug info needed.. Could you elaborate with an example? - FChE