This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 1/4] kprobe-based symbol resolution for stap-translator
- From: Prerna Saxena <prerna at linux dot vnet dot ibm dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 13 Apr 2009 20:39:17 +0530
- Subject: Re: [RFC][PATCH 1/4] kprobe-based symbol resolution for stap-translator
- References: <49BA38DB.1080604@linux.vnet.ibm.com> <y0my6v9r1kn.fsf@ton.toronto.redhat.com> <20090313135005.GB3917@in.ibm.com> <20090313192423.GC16297@redhat.com> <20090409162216.GA10641@redhat.com>
Hi Frank,
Frank Ch. Eigler wrote:
Hi -
I wrote:
[...] I'd rather see
- no new command line option
- a separate namespace for these restricted sorts of probes
- and then some new intelligence in the translator that automatically
downgrades "kernel.function("...")' probes to 'kernel.kprobe("...")'
if the probe point & handler does not appear to require debuginfo
Have you thought more about this approach?
It may be possible to approximate the kernel.function complications
such as wildcards by heuristics that search /proc/kallsyms (and
therefore assuming/warning that the instrumentation host == target).
- FChE
I'm working on a prototype of "probe kprobe.function" type, which I'll
be sending out in a few days. In its basic form, it would defer symbol
resolution to runtime, depending on kernel symbol tables to resolve
function names.
in its first draft this shall not be capable enough to support wildcards
; but its capability might be subsequently extended to search
/proc/kallsyms when the stap probe is instrumented for currently running
kernel.
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India