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

[Josh Stone <jistone at redhat dot com>]

Ananth N Mavinakayanahalli wrote:
> On Fri, Mar 13, 2009 at 02:03:40PM -0700, Josh Stone wrote:
>> I'm leery even of this though, because it seems there's no way to validate 
>> the function name until you actually run it, right?
> 
> I think that fear is an unfounded; as mentioned before, if there are
> namespace clashes, the first 'found' instance is what gets returned. Sure,
> there can be bugs in the kallsyms' function name resolution. That'd be a
> kernel bug and can be fixed.

I understand how kprobes will work in this regard, but that doesn't help
the user, because we don't know until runtime if the function name is
valid.  Right now we can issue an error in the semantic pass if a name
is not found, or provide alternate implementations, as Frank pointed
out.  Consider your own changes in the syscall tapsets:

  probe syscall.read = kernel.function("SyS_read") !,
                       kernel.function("sys_read") { ... }


This could no longer be a compile-time decision with kprobes-based
symbol resolution.  We'd have to compile in both options and make the
decision at runtime.  That may not be too bad in this simple case, but
if it were even slightly more complex, the runtime code will end up a
lot more convoluted.

  probe _syscall_utrace.read =
        process.syscall { if ($syscall != __NR_read) next; }
  probe syscall.read = kernel.function("SyS_read") !,
                       kernel.function("sys_read") !,
                       _syscall_utrace.read { ... }

We allow scripts to do pretty interesting things, but I wouldn't want to
 try to resolve those at runtime...

Josh