kernel.git/tools/perf/util/dso.h, branch linux-rolling-stable

perf tools: Get debug info of DSO properly

2026-03-04T12:19:24Z

[ Upstream commit 069e603d8248dac98b1ef2909e2f1c4169b9da11 ] The dso__debuginfo() just used the path name to open the file but it may be outdated. It should check build-ID and use the file in the build-ID cache if available rather than just using the path name. Let's factor out dso__get_filename() to avoid code duplicate. Fixes: 53a61a6ca279165d ("perf annotate: Add dso__debuginfo() helper") Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

perf dso: Move read_symbol() from llvm/capstone to dso

2025-10-06T19:35:25Z

Move the read_symbol function to dso.h, make the return type const and add a mutable out_buf out parameter. In future changes this will allow a code pointer to be returned without necessary allocating memory. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexandre Ghiti Cc: Andi Kleen Cc: Athira Rajeev Cc: Bill Wendling Cc: Charlie Jenkins Cc: Collin Funk Cc: Dmitriy Vyukov Cc: Dr. David Alan Gilbert Cc: Eric Biggers Cc: Haibo Xu Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Justin Stitt Cc: Li Huafei Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Song Liu Cc: Stephen Brennan Signed-off-by: Arnaldo Carvalho de Melo

perf annotate: Add dso__debuginfo() helper

2025-08-28T15:35:42Z

It'd be great if it can get the correct debug information using DSO build-Id not just the path name. Instead of adding new callsites of debuginfo__new(), let's add dso__debuginfo() which can hide the access using the pathname and help the future conversion. Suggested-by: Ian Rogers Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250816031635.25318-12-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf annotate: Show warning when debuginfo is not available

2025-08-28T15:35:12Z

When user requests data-type annotation but no DWARF info is available, show a warning message about it. Warning: DWARF debuginfo not found. Data-type in this DSO will not be displayed. Please make sure to have debug information. Press any key... Signed-off-by: Namhyung Kim Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20250816031635.25318-10-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf dso: Move build_id to dso_id

2025-07-25T17:37:56Z

The dso_id previously contained the major, minor, inode and inode generation information from a mmap2 event - the inode generation would be zero when reading from /proc/pid/maps. The build_id was in the dso. With build ID mmap2 events these fields wouldn't be initialized which would largely mean the special empty case where any dso would match for equality. This isn't desirable as if a dso is replaced we want the comparison to yield a difference. To support detecting the difference between DSOs based on build_id, move the build_id out of the DSO and into the dso_id. The dso_id is also stored in the DSO so nothing is lost. Capture in the dso_id what parts have been initialized and rename dso_id__inject to dso_id__improve_id so that it is clear the dso_id is being improved upon with additional information. With the build_id in the dso_id, use memcmp to compare for equality. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250724163302.596743-7-irogers@google.com Signed-off-by: Namhyung Kim

perf dso: Add support for reading the e_machine type for a dso

2025-03-21T05:58:02Z

For ELF file dsos read the e_machine from the ELF header. For kernel types assume the e_machine matches the perf tool. In other cases return EM_NONE. When reading from the ELF header use DSO__SWAP that may need dso->needs_swap initializing. Factor out dso__swap_init to allow this. Signed-off-by: Ian Rogers Reviewed-by: Namhyung Kim Acked-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250319050741.269828-7-irogers@google.com Signed-off-by: Namhyung Kim

perf dso: kernel-doc for enum dso_binary_type

2025-03-21T05:57:25Z

There are many and non-obvious meanings to the dso_binary_type enum values. Add kernel-doc to speed interpretting their meanings. Acked-by: Arnaldo Carvalho de Melo Signed-off-by: Ian Rogers Reviewed-by: Namhyung Kim Link: https://lore.kernel.org/r/20250319050741.269828-3-irogers@google.com Signed-off-by: Namhyung Kim

perf dso: Move libunwind dso_data variables into ifdef

2025-03-21T05:56:29Z

The variables elf_base_addr, debug_frame_offset, eh_frame_hdr_addr and eh_frame_hdr_offset are only accessed in unwind-libunwind-local.c which is conditionally built on having libunwind support. Make the variables conditional on libunwind support too. Reviewed-by: Arnaldo Carvalho de Melo Signed-off-by: Ian Rogers Reviewed-by: Namhyung Kim Acked-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20250319050741.269828-2-irogers@google.com Signed-off-by: Namhyung Kim

perf dso: fix dso__is_kallsyms() check

2025-03-19T23:56:05Z

Kernel modules for which we cannot find a file on-disk will have a dso->long_name that looks like "[module_name]". Prior to the commit listed in the fixes, the dso->kernel field would be zero (for user space), so dso__is_kallsyms() would return false. After the commit, kernel module DSOs are correctly labeled, but the result is that dso__is_kallsyms() erroneously returns true for those modules without a filesystem path. Later, build_id_cache__add() consults this value of is_kallsyms, and when true, it copies /proc/kallsyms into the cache. Users with many kernel modules without a filesystem path (e.g. ksplice or possibly kernel live patch modules) have reported excessive disk space usage in the build ID cache directory due to this behavior. To reproduce the issue, it's enough to build a trivial out-of-tree hello world kernel module, load it using insmod, and then use: perf record -ag -- sleep 1 In the build ID directory, there will be a directory for your module name containing a kallsyms file. Fix this up by changing dso__is_kallsyms() to consult the dso_binary_type enumeration, which is also symmetric to the above checks for dso__is_vmlinux() and dso__is_kcore(). With this change, kallsyms is not cached in the build-id cache for out-of-tree modules. Fixes: 02213cec64bbe ("perf maps: Mark module DSOs with kernel type") Signed-off-by: Stephen Brennan Link: https://lore.kernel.org/r/20250318230012.2038790-1-stephen.s.brennan@oracle.com Signed-off-by: Namhyung Kim

perf dso: Use lock annotations to fix asan deadlock

2025-03-18T05:07:18Z

dso__list_del with address sanitizer and/or reference count checking will call dso__put that can call dso__data_close reentrantly trying to lock the dso__data_open_lock and deadlocking. Switch from pthread mutexes to perf's mutex so that lock checking is performed in debug builds. Add lock annotations that diagnosed the problem. Release the dso__data_open_lock around the dso__put to avoid the deadlock. Change the declaration of dso__data_get_fd to return a boolean, indicating the fd is valid and the lock is held, to make it compatible with the thread safety annotations as a try lock. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250318043151.137973-3-irogers@google.com Signed-off-by: Namhyung Kim