Skip to content

Commit a2439a4

Browse files
committed
Documentation: tracing: Update fprobe event example with BTF field
Update fprobe event example with BTF data structure field specification. Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
1 parent d892d3d commit a2439a4

File tree

1 file changed

+46
-18
lines changed

1 file changed

+46
-18
lines changed

Documentation/trace/fprobetrace.rst

Lines changed: 46 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -79,9 +79,9 @@ automatically set by the given name. ::
7979
f:fprobes/myprobe vfs_read count=count pos=pos
8080

8181
It also chooses the fetch type from BTF information. For example, in the above
82-
example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus, both
83-
are converted to 64bit unsigned long, but only ``pos`` has "%Lx" print-format as
84-
below ::
82+
example, the ``count`` is unsigned long, and the ``pos`` is a pointer. Thus,
83+
both are converted to 64bit unsigned long, but only ``pos`` has "%Lx"
84+
print-format as below ::
8585

8686
# cat events/fprobes/myprobe/format
8787
name: myprobe
@@ -105,9 +105,47 @@ is expanded to all function arguments of the function or the tracepoint. ::
105105
# cat dynamic_events
106106
f:fprobes/myprobe vfs_read file=file buf=buf count=count pos=pos
107107

108-
BTF also affects the ``$retval``. If user doesn't set any type, the retval type is
109-
automatically picked from the BTF. If the function returns ``void``, ``$retval``
110-
is rejected.
108+
BTF also affects the ``$retval``. If user doesn't set any type, the retval
109+
type is automatically picked from the BTF. If the function returns ``void``,
110+
``$retval`` is rejected.
111+
112+
You can access the data fields of a data structure using allow operator ``->``
113+
(for pointer type) and dot operator ``.`` (for data structure type.)::
114+
115+
# echo 't sched_switch preempt prev_pid=prev->pid next_pid=next->pid' >> dynamic_events
116+
117+
The field access operators, ``->`` and ``.`` can be combined for accessing deeper
118+
members and other structure members pointed by the member. e.g. ``foo->bar.baz->qux``
119+
If there is non-name union member, you can directly access it as the C code does.
120+
For example::
121+
122+
struct {
123+
union {
124+
int a;
125+
int b;
126+
};
127+
} *foo;
128+
129+
To access ``a`` and ``b``, use ``foo->a`` and ``foo->b`` in this case.
130+
131+
This data field access is available for the return value via ``$retval``,
132+
e.g. ``$retval->name``.
133+
134+
For these BTF arguments and fields, ``:string`` and ``:ustring`` change the
135+
behavior. If these are used for BTF argument or field, it checks whether
136+
the BTF type of the argument or the data field is ``char *`` or ``char []``,
137+
or not. If not, it rejects applying the string types. Also, with the BTF
138+
support, you don't need a memory dereference operator (``+0(PTR)``) for
139+
accessing the string pointed by a ``PTR``. It automatically adds the memory
140+
dereference operator according to the BTF type. e.g. ::
141+
142+
# echo 't sched_switch prev->comm:string' >> dynamic_events
143+
# echo 'f getname_flags%return $retval->name:string' >> dynamic_events
144+
145+
The ``prev->comm`` is an embedded char array in the data structure, and
146+
``$retval->name`` is a char pointer in the data structure. But in both
147+
cases, you can use ``:string`` type to get the string.
148+
111149

112150
Usage examples
113151
--------------
@@ -161,10 +199,10 @@ parameters. This means you can access any field values in the task
161199
structure pointed by the ``prev`` and ``next`` arguments.
162200

163201
For example, usually ``task_struct::start_time`` is not traced, but with this
164-
traceprobe event, you can trace it as below.
202+
traceprobe event, you can trace that field as below.
165203
::
166204

167-
# echo 't sched_switch comm=+1896(next):string start_time=+1728(next):u64' > dynamic_events
205+
# echo 't sched_switch comm=next->comm:string next->start_time' > dynamic_events
168206
# head -n 20 trace | tail
169207
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
170208
# | | | ||||| | |
@@ -176,13 +214,3 @@ traceprobe event, you can trace it as below.
176214
<idle>-0 [000] d..3. 5606.690317: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
177215
kworker/0:1-14 [000] d..3. 5606.690339: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="swapper/0" usage=2 start_time=0
178216
<idle>-0 [000] d..3. 5606.692368: sched_switch: (__probestub_sched_switch+0x4/0x10) comm="kworker/0:1" usage=1 start_time=137000000
179-
180-
Currently, to find the offset of a specific field in the data structure,
181-
you need to build kernel with debuginfo and run `perf probe` command with
182-
`-D` option. e.g.
183-
::
184-
185-
# perf probe -D "__probestub_sched_switch next->comm:string next->start_time"
186-
p:probe/__probestub_sched_switch __probestub_sched_switch+0 comm=+1896(%cx):string start_time=+1728(%cx):u64
187-
188-
And replace the ``%cx`` with the ``next``.

0 commit comments

Comments
 (0)