Re: [RFC][PATCH 1/4] kprobe-based symbol resolution for stap-translator

[Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>]

On Fri, Mar 13, 2009 at 09:31:52AM -0400, Frank Ch. Eigler wrote:
> 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.

I do see merit in having such a bare-bones option available to users.
Very simple cases as counting of number of calls to a particular
routine, etc., can very well be handled by this approach.

I don't see why we need a new construct. The changes to translator
seem fairly self contained with this patchset along with an independent
option. With just the command line switch, the benefit is that simple
scripts cited above would 'just work' and IMO, that's a big usability
win.

Further, the work Jim and I did for parameter access using arg*
(registers.stp) should just work with this approach too -- so we'll have
a feature that's fairly close to what we had earlier. Agreed,
restoration of the earlier dwarfless support does have its own benefits.

Ananth