@@ -79,9 +79,9 @@ automatically set by the given name. ::
7979 f:fprobes/myprobe vfs_read count=count pos=pos
8080
8181It 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
112150Usage examples
113151--------------
@@ -161,10 +199,10 @@ parameters. This means you can access any field values in the task
161199structure pointed by the ``prev `` and ``next `` arguments.
162200
163201For 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