This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]