Re: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)
From: Frank Ch. Eigler
Date: Thu Jul 17 2008 - 16:29:04 EST
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
> 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
> 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?
> Then you can't offset into other sections, like init sections or
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
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/