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