Listing probe alias resolution failures

[patm@pdx.edu]

Quoting David Smith <dsmith@redhat.com>:

> patm@pdx.edu wrote:
>> With (version 0.5.14 built 2007-04-30) of systemtap and kernel   
>> 2.6.19.7 (i386), there are a lot (~220) of failures in the tapset   
>> like the following:
>>
>> semantic error: no match for probe point while resolving probe   
>> point vm.write_shared_copy
>>
>> To get a list of all of these, I pulled out some code from the   
>> systemtap GUI and made a quick standalone java program   
>> "listprobes", it works like the following:
>
> I'm not a java programmer, but it appears like you might be expecting
> every function listed in the tapsets to be resolvable on a particular
> kernel.  This isn't the case.  Let's take an easy example - the probe
> alias syscall.open (in tapset/syscalls2.stp):
>
> =============
> probe syscall.open =
> 		kernel.function("sys_open") ?,
> 		kernel.function("compat_sys_open") ?,
> 		kernel.function("sys32_open") ?
> {
> ...
> }
> =============

The java program lists all of the probe aliases, not their  
corresponding kernel funtion(s). So all of the failures listed are for  
the probe alias, which must happen as you described above, after  
exhausting all listed kernel.functions and modules mapped to in the  
probe definition.

> This probe alias looks for "sys_open" first, then if it doesn't exist
> looks for "compat_sys_open", then looks for "sys32_open".  If
> "sys_open" exists in your kernel, it isn't an error that
> "compat_sys_open" and "sys32_open" do not exist.
>
> In actual use, if you've gotten "no match for probe point" errors let
> us know and we'll try to fix them.
>
> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)