From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5179 invoked by alias); 17 Jul 2008 22:05:14 -0000 Received: (qmail 5172 invoked by uid 22791); 17 Jul 2008 22:05:14 -0000 X-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_05,J_CHICKENPOX_66,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.31) with ESMTP; Thu, 17 Jul 2008 22:04:56 +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 m6HM4rEi024894; Thu, 17 Jul 2008 18:04:53 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6HM4q1A020663; Thu, 17 Jul 2008 18:04:53 -0400 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m6HM4q9s008853; Thu, 17 Jul 2008 18:04:52 -0400 Message-ID: <487FC1B0.1090105@redhat.com> Date: Thu, 17 Jul 2008 22:05:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: James Bottomley , linux-kernel , systemtap@sourceware.org Subject: Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address) References: <487E78ED.30804@redhat.com> <1216249383.3358.69.camel@localhost.localdomain> <487E8CE4.70105@redhat.com> <1216259391.3358.85.camel@localhost.localdomain> <1216304290.5515.11.camel@localhost.localdomain> <1216313914.5515.25.camel__21144.9282979176$1216314027$gmane$org@localhost.localdomain> <1216325546.5515.63.camel@localhost.localdomain> <20080717202634.GI18295@redhat.com> <1216328769.5515.78.camel@localhost.localdomain> <20080717213355.GJ18295@redhat.com> In-Reply-To: <20080717213355.GJ18295@redhat.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00237.txt.bz2 Frank Ch. Eigler wrote: > Hi - > > > On Thu, Jul 17, 2008 at 04:06:09PM -0500, James Bottomley wrote: > >> [...] >>> My point is that the proposed effort to identify a nearby function >>> symbol to use as a base for each probe's symbol+offset calculation is >>> wasted. >> It's not exactly wasted ... the calculations have to be done anyway for >> modules. > > Not really - we just anchor off a different (per-module) reference > symbol or address. At the moment, we use the .text* section bases. > > >>>> you've lost access to the symbols in the sections that start before _stext. >>> What's between _text and _stext appears to consist of kernel boot-time >>> functions that are unmapped the time anything like systemtap could >>> run. >> Well, no, they're the head code. It's actually used in CPU boot and >> tear down, one of the things it's useful to probe, I think. > > Fair enough - conceivably probing that stuff is useful, as is module > initialization. We don't try to do it yet (and indeed kprobes blocks > it all). > > In any case, the method of probe address calculation doesn't affect > that issue. We can calculate .init* addresses relative to any > convenient reference in exactly the same way as non-.init addresses. > > >>>> Assuming you meant _text (which is dangerous because it's a define >>>> in the kernel linker script and could change). >>> By "dangerous" do you only mean that it may require a one-liner >>> catch-up patch in systemtap if the kernel linker scripts change? >> Dangerous as in it's not necessarily part of the kernel linker scripts. >> [...] >> The point, really, is to remove some of the fragile dependencies between >> systemtap and the kernel. > > Yes, that is generally desirable - each case is usually a question of > cost/benefit. One significant requirement for us is to keep working > with older kernels. Hi Frank, I know we'd better archive that requirement. However, if we lose support from developers because we are too much focusing on that, we'll also lose the future of systemtap itself. We have to see the cost/benefit from the long-term of view. Could we separate systemtap parser/elaborator and code generator to support both of old and new kernels? Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com