On Sat, 21 Jan 2023 15:31:08 +0100 Yoann Congal <yoann.congal@xxxxxxxx> wrote: > @@ -76,14 +76,15 @@ or 'x64' is used depends on the architecture (e.g. x86-32 uses x32, and > x86-64 uses x64). > These value types can be an array. To record array data, you can add '[N]' > (where N is a fixed number, less than 64) to the base type. > -E.g. 'x16[4]' means an array of x16 (2bytes hex) with 4 elements. > +E.g. 'x16[4]' means an array of x16 (2-bytes hex) with 4 elements. As we are correcting this, let's correct it correctly ;-) Adjectives do not turn into plurals. It's "2-byte hex" not "2-bytes hex". Thanks, -- Steve > Note that the array can be applied to memory type fetchargs, you can not > apply it to registers/stack-entries etc. (for example, '$stack1:x8[8]' is > wrong, but '+8($stack):x8[8]' is OK.) > String type is a special type, which fetches a "null-terminated" string from > kernel space. This means it will fail and store NULL if the string container > has been paged out. "ustring" type is an alternative of string for user-space. > -See :ref:`user_mem_access` for more info.. > +See :ref:`user_mem_access` for more info. > + > The string array type is a bit different from other types. For other base > types, <base-type>[1] is equal to <base-type> (e.g. +0(%di):x32[1] is same > as +0(%di):x32.) But string[1] is not equal to string. The string type itself > @@ -120,8 +121,8 @@ space. 'ustring' is a shortcut way of performing the same task. That is, > > Note that kprobe-event provides the user-memory access syntax but it doesn't > use it transparently. This means if you use normal dereference or string type > -for user memory, it might fail, and may always fail on some archs. The user > -has to carefully check if the target data is in kernel or user space. > +for user memory, it might fail, and may always fail on some architectures. The > +user has to carefully check if the target data is in kernel or user space. > > Per-Probe Event Filtering > ------------------------- > --
