Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

["Frank Ch. Eigler" <fche@redhat.com>]

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