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

[Ananth N Mavinakayanahalli <ananth@in.ibm.com>]

On Fri, Mar 13, 2009 at 02:03:40PM -0700, Josh Stone wrote:
> Frank Ch. Eigler wrote:
>> - 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
>
> This downgrade could only occur for .call variants, right?  A plain 
> 'kernel.function("...")' could exist as both a standalone function and as 
> an inline instance if gcc is being clever...

Yes, kallsyms_lookup_name() works only with .call. It can and will return
only one address per symbol; it won't even resolve compiler inlined
instances (many of the signal tapset failures are a result of such
inlining).

> 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.

Ananth