Re: [RFC] systemtap: begin the process of using proper kernel APIs(part1: use kprobe symbol_name/offset instead of address)
From: James Bottomley
Date: Thu Jul 17 2008 - 17:06:25 EST
On Thu, 2008-07-17 at 16:26 -0400, Frank Ch. Eigler wrote:
> Hi -
> On Thu, Jul 17, 2008 at 03:12:26PM -0500, James Bottomley wrote:
> > [...]
> > > Can you explain in detail how you believe this is materially
> > > different from offsetting from _stext?
> > Basically because _stext is an incredibly dangerous symbol; being linker
> > generated it doesn't actually get put in the right place if you look:
> Thank you for your response.
> > jejb@sparkweed> nm vmlinux |egrep -w '_stext|_text'
> > ffffffff80209000 T _stext
> > ffffffff80200000 A _text
> > Since we can't do negative offsets
> Actually, "we" as in systemtap could do it just fine if that were
> desired. And really _stext is therefore an arbitrary choice - it
> could be any other reference.
> 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
It's not exactly wasted ... the calculations have to be done anyway for
> > 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
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.
> > 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.
Some arches have it defined as a symbol, some have it as a linker script
definition ... that's why it's location is strange.
The point, really, is to remove some of the fragile dependencies between
systemtap and the kernel.
> > Then you can't offset into other sections, like init sections or
> > modules.
> Kernel init sections are unprobeable by definition, so that doesn't
> matter. Modules are also irrelevant, since their addresses are
> relative to their relocation bases / sections, not to a kernel
> (vmlinux) symbol.
Then the definition needs altering. I can see that the industrial
customers aren't interested but kernel developers are ... a lot of
problems occur in the init sections.
I think you'll find that systemtap will run quite happily from a shell
in an initramfs before the init sections are discarded. Plus there's
always module init sections which can appear at any time.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/