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]

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


------- 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.


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