Messages in this thread | | | Subject | 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, 17 Jul 2008 16:06:09 -0500 |
| |
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 > wasted.
It's not exactly wasted ... the calculations have to be done anyway for modules.
> > 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.
> > 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.
James
| |