This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 11 Jan 2008 14:58:18 -0000
- Subject: [Bug tapsets/5510] no match while resolving probe point sunrpc.sched.release_task.return
- References: <20071219011502.5510.baiwd@cn.fujitsu.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.