From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21655 invoked by alias); 17 Jul 2008 21:35:32 -0000 Received: (qmail 21647 invoked by uid 22791); 17 Jul 2008 21:35:32 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,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 21:35:15 +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 m6HLZBug013466; Thu, 17 Jul 2008 17:35:11 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6HLZ97I005441; Thu, 17 Jul 2008 17:35:10 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6HLYSwJ005331; Thu, 17 Jul 2008 17:35:01 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 22ACA8001FF; Thu, 17 Jul 2008 17:34:11 -0400 (EDT) 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 m6HLXtGI031810; Thu, 17 Jul 2008 17:33:55 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m6HLXt9L031809; Thu, 17 Jul 2008 17:33:55 -0400 Date: Thu, 17 Jul 2008 21:35:00 -0000 From: "Frank Ch. Eigler" To: James Bottomley Cc: Masami Hiramatsu , 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) Message-ID: <20080717213355.GJ18295@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1216328769.5515.78.camel@localhost.localdomain> 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-q3/txt/msg00233.txt.bz2 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. - FChE