Re: help: semantic error: no match while resolving probe point module

[Wendy Cheng <s dot wendy dot cheng at gmail dot com>]

On Wed, Nov 28, 2012 at 8:36 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
>
> That sounds like a partial workaround for <http://sourceware.org/PR14454>.
>

I can't read Red Hat bugzilla 846789 :) .. Access Denied ..
Fortunately, hand-copy the driver to the /lib/modules directory works.

>
> (By the way, you could consider using the para-callgraph.stp script
> from the distributed samples:)
>
> # stap /usr/share/doc/systemtap*/examples/*/para-callgraph.stp \
>        'module("*ib_ipoib*").function("*")'

Thanks !

>
> Is it possible that the newly booted kernel was a different version
> than the one before, and that copy of /lib/modules/`uname -r` didn't
> have your new ip* module bits in it?  "stap --vp 02 ipoib.stap" should
> give a little more clue about where stap is looking for files.
>
>
I only have one kernel installed. The "--vp 02" was disappointing. It
did not reveal anything when things *went wrong*. The good news is
.... (see below)

You did, however, give me a good hint of where to look. I was working
on an embeded kmod for Intel Xeon Phi - it was a card plugged into the
host machine where stap was running. The drivers on the host and card
currently shared the same source tree and were built togather. As I
rebuilt, the files in the tree changed but I didn't bother to update
the host driver (in /lib/modules) as the old built driver should have
worked (logically) w/out the changes. After the host driver was
updated (in /lib/modules), stap started to work magically again. This
time, "--vp 02" shows there is a cache file located in
~/.systemtap/cache/ directory where I find stap looks for symbols in
my build tree.

Great thanks !

-- Wendy