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: Listing probe alias resolution failures


David Smith wrote:
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") ?
{
...
}
=============

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.

Unless something has changed, I don't think that's how it works. The '?' suffix just tells stap not to report an error if the function can't be found. Stap still looks for all three functions. For example, if sys_open and compat_sys_open are both found then both have probes placed on them.


Mike


In actual use, if you've gotten "no match for probe point" errors let us know and we'll try to fix them.




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