This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 5510
  no match while resolving probe point sunrpc.sched.release_task.return Last modified: 2008-01-11 14:58:18
     Query page      Enter new bug
Bug#: 5510   Hardware:   Reporter: Weidong Bai <baiwd@cn.fujitsu.com>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Status: NEW   Priority:  
Resolution:   Severity:  
Assigned To: Unassigned <systemtap@sources.redhat.com>   Target Milestone:  
Summary:
Keywords:

Attachment Description Type Created Actions
rpc.patch add missed "?" behind sunrpc.sched.release_task.return patch 2007-12-21 07:47 Edit | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 5510 depends on: Show dependency tree
Show dependency graph
Bug 5510 blocks:

Additional Comments:


Leave as NEW 
Mark bug as waiting for feedback
Mark bug as suspended
Accept bug (change status to ASSIGNED)
Resolve bug, changing resolution to
Resolve bug, mark it as duplicate of bug #
Reassign bug to
Reassign bug to owner of selected component

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2007-12-19 01:15
On RHEL5.1, I test systemtap(20071215 version) with
buildok/rpc-all-probes.stp, it reports that:
Pass 1: parsed user script and 38 library script(s) in 306usr/5sys/310real ms.
semantic error: no match while resolving probe point
sunrpc.sched.release_task.return

     I think that this is caused by that sunrpc.sched.release_task.return is not
necessarily exist. As you can see:
probe sunrpc.sched.release_task.return =
kernel.function("rpc_release_task").return ?,
module("sunrpc").function("rpc_release_task").return ?
{
name = "sunrpc.sched.release_task.return"
} 

     So I want to change it as follwowing:
--- /home/baiwd/stapsrc/src/tapset/rpc.stp 2007-11-08 11:02:47.000000000 +0900
+++ ./rpc.stp 2007-12-18 18:39:44.000000000 +0900
@@ -724,7 +724,7 @@ probe sunrpc.sched.entry =

probe sunrpc.sched.return =
sunrpc.sched.new_task.return,
- sunrpc.sched.release_task.return,
+ sunrpc.sched.release_task.return ?,
sunrpc.sched.execute.return,
sunrpc.sched.delay.return
{} 

    Is this fix right?

------- Additional Comment #1 From Masami Hiramatsu 2007-12-19 19:22 -------
rpc_release_task() is a static function and it may be inlined.
In that case, your patch is good to me.

------- Additional Comment #2 From Weidong Bai 2007-12-21 07:47 -------
Created an attachment (id=2155)
add missed "?" behind sunrpc.sched.release_task.return

------- Additional Comment #3 From Masami Hiramatsu 2008-01-09 23:22 -------
(In reply to comment #0)
> probe sunrpc.sched.release_task.return =
> kernel.function("rpc_release_task").return ?,
> module("sunrpc").function("rpc_release_task").return ?
> {
> name = "sunrpc.sched.release_task.return"
> } 

Hmm, this code is a bit odd, because it will cause an error 
if both probe points do not exist.
I think this should use "never" and "!" like below.

---
probe sunrpc.sched.release_task.return =
kernel.function("rpc_release_task").return !,
module("sunrpc").function("rpc_release_task").return !,
never {...
---

------- Additional Comment #4 From Josh Stone 2008-01-10 15:43 -------
(In reply to comment #3)
> I think this should use "never" and "!" like below.
> 
> ---
> probe sunrpc.sched.release_task.return =
> kernel.function("rpc_release_task").return !,
> module("sunrpc").function("rpc_release_task").return !,
> never {...
> ---

Be careful with the use of 'never', because it will cause things to silently
fail.  A simple script like:

  probe sunrpc.sched.release_task.return { println("Hi!") }

... might end up with no real probes at all.

------- Additional Comment #5 From Masami Hiramatsu 2008-01-11 03:51 -------
(In reply to comment #4)
> Be careful with the use of 'never', because it will cause things to silently
> fail.  A simple script like:
> 
>   probe sunrpc.sched.release_task.return { println("Hi!") }
> 
> ... might end up with no real probes at all.

Sure, and I thought 'never' was introduced for that kind of use.
(I think 'never' might better cause some warning message)
IMHO, to completely solve this issue, we need to wait for bz4413 solution.

------- Additional Comment #6 From Frank Ch. Eigler 2008-01-11 14:58 -------
Just to recap, the issue here is that we would prefer to have a return probe
on a function that gcc may at its whim inline.  kretprobes cannot work on such
functions, and until bug #4413 is fixed, we don't have an alternative either.
So, the tapset needs to designate this as an optional probe somehow.  The
question is how.

It seems to me that the most appropriate fix is to add the "?" optional marker
into the big alias list, as comment #0 suggested:

  probe sunrpc.sched.return =
  sunrpc.sched.new_task.return,
  sunrpc.sched.release_task.return ?,
  sunrpc.sched.execute.return,
  sunrpc.sched.delay.return
  {} 

In addition, since these probes may be either kernel- or module-resident,
each individual subprobe could use the "!" notation thusly:

  probe sunrpc.sched.release_task.return =
  kernel.function("rpc_release_task").return !,
  module("sunrpc").function("rpc_release_task").return
  {
     name = "sunrpc.sched.release_task.return"
  }

This is equivalent to the flipped-around one:
  probe module(...) ! , kernel   { }

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In