summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/lists.py
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2025-01-17 03:39:57 +0300
committerDaniel Borkmann <daniel@iogearbox.net>2025-01-17 17:16:56 +0300
commitf8a05692de060a889fe5b9eb00cc8f1fc8935899 (patch)
tree0b7d37e869f898dba1aa11252f214a178e8f0fb0 /scripts/gdb/linux/lists.py
parentb53b63dbf3748eca32e8d19d56dba43ddfec78e6 (diff)
downloadlinux-f8a05692de060a889fe5b9eb00cc8f1fc8935899.tar.xz
libbpf: Work around kernel inconsistently stripping '.llvm.' suffix
Some versions of kernel were stripping out '.llvm.<hash>' suffix from kerne symbols (produced by Clang LTO compilation) from function names reported in available_filter_functions, while kallsyms reported full original name. This confuses libbpf's multi-kprobe logic of finding all matching kernel functions for specified user glob pattern by joining available_filter_functions and kallsyms contents, because joining by full symbol name won't work for symbols containing '.llvm.<hash>' suffix. This was eventually fixed by [0] in the kernel, but we'd like to not regress multi-kprobe experience and add a work around for this bug on libbpf side, stripping kallsym's name if it matches user pattern and contains '.llvm.' suffix. [0] fb6a421fb615 ("kallsyms: Match symbols exactly with CONFIG_LTO_CLANG") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250117003957.179331-1-andrii@kernel.org
Diffstat (limited to 'scripts/gdb/linux/lists.py')
0 files changed, 0 insertions, 0 deletions