On Mon, Aug 03, 2026 at 05:08:39PM -0400, Aaron Tomlin wrote:
> When inspecting kernel execution flows using 'perf trace' (e.g., when
> monitoring workqueues delayed work items, timer callbacks, etc.),
> tracepoint payload arguments containing raw kernel virtual addresses are
> currently rendered as hexadecimal values (e.g., 0xffffffff81234567).
>
> This requires manual symbol lookups against /proc/kallsyms or vmlinux to
> identify the underlying kernel function being executed.
>
> This patch series enhances 'perf trace' by introducing kernel virtual
> address and function pointer symbolisation using perf's native symbol
> engine (i.e., machine__find_kernel_symbol()).
>
> Before:
> workqueue:workqueue_execute_end(work: 0xffffffffab2f1420, function: 0xffffffffa8046b50)
>
> After:
> workqueue:workqueue_execute_end(work: 0xffff8ac2c420f270, function: wb_update_bandwidth_workfn)
>
> Patch 1 adds the 'syscall_arg__scnprintf_ksym' ('SCA_KSYM') beautifier
> which resolves virtual addresses via machine__find_kernel_symbol(),
> formatting them as 'symbol_name+offset' (or "NULL" with a hex fallback).
>
> Patch 2 updates event format initialisation in
> syscall_arg_fmt__init_array() to automatically assign SCA_KSYM to
> tracepoint fields named 'function', 'fn', 'work', 'action', or 'callsite',
> as well as fields typed as function pointers.
>
> Patch 3 extends BTF pretty-printing in trace__btf_scnprintf() with
> btf_is_func_ptr() to automatically detect BTF function prototypes and
> symbolise kernel function pointers without requiring manual field table
> configuration.
>
> Aaron Tomlin (3):
> perf trace: Introduce kernel symbol beautifier for virtual addresses
> perf trace: Auto-assign kernel symbol beautifier to function pointer
> fields
> perf trace: Enhance BTF type formatting to symbolise kernel function
> pointers
>
> tools/perf/builtin-trace.c | 76 ++++++++++++++++++++++++++++----
> tools/perf/trace/beauty/beauty.h | 3 ++
> 2 files changed, 71 insertions(+), 8 deletions(-)
>
> --
> 2.55.0
Hi Ian, Arnaldo, Namhyung,
Kindly ignore this series for now.
I would prefer to wait for series [1] and patch [2] to be merged. Thanks.
[1]: https://lore.kernel.org/lkml/20260802210914.199941-1-atomlin@atomlin.com/
[2]: https://lore.kernel.org/lkml/20260803124845.213165-1-atomlin@atomlin.com/
Kind regards,
--
Aaron Tomlin