[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=5510

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #7 from Frank Ch. Eigler <fche at redhat dot com> ---
this particular ? has been added long ago

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  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   { }


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  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 {...
---


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[baiwd at cn dot fujitsu dot com]

------- Additional Comments From baiwd at cn dot fujitsu dot com  2007-12-21 07:47 -------
Created an attachment (id=2155)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2155&action=view)
add missed "?" behind sunrpc.sched.release_task.return


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=5510

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.