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: fche at redhat dot com (Frank Ch. Eigler)
- To: Prerna Saxena <prerna at linux dot vnet dot ibm dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 13 Mar 2009 09:31:52 -0400
- Subject: Re: [RFC][PATCH 1/4] kprobe-based symbol resolution for stap-translator
- References: <49BA38DB.1080604@linux.vnet.ibm.com>
Prerna Saxena <prerna@linux.vnet.ibm.com> writes:
> Here's a set of patches which enable the stap-translator to utilize
> kprobes for resolving function addresses. ( Similar to James
> Bottomley's patch sent out last july ) In place of resolving probe
> points in semantic pass (Pass 2 ) by consulting vmlinux/debuginfo,
> this approach defers symbol resolution to the generated kprobes
> module. [...]
I remain unfond of this approach for a variety of reasons. Perhaps the
best thing is to add this as a separate probe point family entirely,
like kernel.kprobe("name") Then there will be no expectation
that wildcards or $-variables should work, nor would there be any
disruption to the dwarf-based code currently in the translator.
> In its present form, it is capable of probing function entry & returns
> (non-inlines). It does /*not*/ support :
> * a wildcard - based search for module/function names
The re-forthcoming symbol-table-based probing would enable this.
> * probing select/all functions in a given source file
> * probing inline functions.
> * statement probes
And of course these are impossible without debuginfo
- FChE