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

From: Masami Hiramatsu
Date: Wed Jul 16 2008 - 18:43:05 EST

James Bottomley wrote:
> One of the big nasties of systemtap is the way it tries to embed
> virtually the entirety of the kernel symbol table in the probe modules
> it constructs. This is highly undesirable because it represents a
> subversion of the kernel API to gain access to unexported symbols. At
> least for kprobes, the correct way to do this is to specify the probe
> point by symbol and offset.
> This patch converts systemtap to use the correct kprobe
> symbol_name/offset pair to identify the probe location.

Hi James,

I think your suggestion is a good step. Of course, it might
have to solve some issues.

Unfortunately, current kprobe's symbol_name interface is not
so clever. For example, if you specify a static function
which is defined at several places in the kernel(ex. do_open),
it always pick up the first one in kallsyms, even if systemtap
can find all of those functions.
(you can find many duplicated symbols in /proc/kallsyms)

So, we might better improve kallsyms to treat this case
and find what is a better way to specify symbols and addresses.

> This only represents a baby step: after this is done, there are at
> least three other consumers of the systemtap module relocation
> machinery:
> 1. unwind information. I think the consumers of this can be
> converted to use the arch specific unwinders that already exist
> within the kernel
> 2. systemtap specific functions that use kernel internals. This
> was things like get_cycles() but I think they all now use a
> sanctioned API ... need to check

Sure, those functions must be well isolated from other parts of kernel.
unfortunately, relayfs is not enough isolated. see below;

> 3. Access to unexported global variables used by the probes. This
> one is a bit tricky; the dwarf gives a probe the ability to
> access any variable available from the probed stack frame,
> including all globals. We could just make the globals off
> limits, but that weakens the value of the debugger.
> Alternatively, we could expand the kprobe API to allow probes
> access to named global variables (tricky to get right without
> effectively giving general symbol access). Thoughts?

Could we provide a separated GPL'd interface to access named global
symbols which is based on kallsyms?

Thank you,

> If you're going to try this out, you currently need to specify --kelf on
> the command line to tell systemtap to use the kernel elf to derive
> symbol names and offsets (it will just segfault without this ATM).
> James

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@xxxxxxxxxx

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at