On Wed, 17 May 2023 19:59:04 +0900
"Masami Hiramatsu (Google)" [off-list ref] wrote:

Add fprobe events for tracing function entry and exit instead of kprobe
events. With this change, we can continue to trace function entry/exit
even if the CONFIG_KPROBES_ON_FTRACE is not available. Since
CONFIG_KPROBES_ON_FTRACE requires the CONFIG_DYNAMIC_FTRACE_WITH_REGS,
it is not available if the architecture only supports
CONFIG_DYNAMIC_FTRACE_WITH_ARGS. And that means kprobe events can not
probe function entry/exit effectively on such architecture.
But this can be solved if the dynamic events supports fprobe events.

The fprobe event is a new dynamic events which is only for the function
(symbol) entry and exit. This event accepts non register fetch arguments
so that user can trace the function arguments and return values.

The fprobe events syntax is here;

 f[:[GRP/][EVENT]] FUNCTION [FETCHARGS]
 f[MAXACTIVE][:[GRP/][EVENT]] FUNCTION%return [FETCHARGS]

I finally got around to look at these (I know you already queued them), but
looking at the above, the "%return" is redundant.

E.g.

 # echo 'f vfs_read $arg1'  >> dynamic_events
 # echo 'f vfs_read%return $retval'  >> dynamic_events
 # cat dynamic_events
 f:fprobes/vfs_read__entry vfs_read arg1=$arg1
 f:fprobes/vfs_read__exit vfs_read%return arg1=$retval

Can't we just have:

  f:fprobes/vfs_read__entry vfs_read arg1=$arg1
  f:fprobes/vfs_read__exit vfs_read arg1=$retval

Where if "$retval" is specified, it automatically becomes a return? If
anything else is specified, it errors out. That is, if $retval is
specified, it becomes a return probe, as a return probe can only have
$retval. If anything else is specified, it errors out if $retval is also
specified.

Now if it's a void function, and you just want to make it a return then we
can have your:

  f:fprobes/vfs_read__exit vfs_read%return

Thoughts?

-- Steve