| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAP-5=fWWHHioXCsZhxL=ooEPD_qZyd78t0Qjj1ieZYSB-Z_fsg@mail.gmail.com> Date: Mon, 12 Jan 2026 06:49:39 -0800 From: Ian Rogers <irogers@...gle.com> To: James Clark <james.clark@...aro.org> Cc: Tony Jones <tonyj@...e.de>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, Howard Chu <howardchu95@...il.com>, Stephen Brennan <stephen.s.brennan@...cle.com>, linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org Subject: Re: [PATCH v3 0/7] perf: Add a libdw addr2line implementation On Mon, Jan 12, 2026 at 3:18 AM James Clark <james.clark@...aro.org> wrote: > > On 11/01/2026 4:13 am, Ian Rogers wrote: > > addr2line is a performance bottleneck in perf, add a libdw based > > implementation that avoids forking addr2line and caches the decoded > > debug information. > > > > Allow the addr2line implementation to be picked via the configuration > > file or --addr2line-style with `perf report`. > > > > Test/fix that inline callchains are properly displayed by perf script. > > > > An example: > > ``` > > $ perf record --call-graph dwarf -e cycles:u -- perf test -w inlineloop 1 > > [ perf record: Woken up 132 times to write data ] > > [ perf record: Captured and wrote 32.814 MB perf.data (4074 samples) ] > > $ perf script --fields +srcline > > ... > > perf-inlineloop 1814670 293100.228871: 640004 cpu_core/cycles/u: > > 55a11d6e61ee leaf+0x2e > > inlineloop.c:21 (inlined) > > 55a11d6e61ee middle+0x2e > > inlineloop.c:27 (inlined) > > 55a11d6e61ee parent+0x2e (perf) > > inlineloop.c:32 > > 55a11d6e629b inlineloop+0x8b (perf) > > inlineloop.c:47 > > 55a11d69a3bc run_workload+0x5a (perf) > > builtin-test.c:715 > > 55a11d69aa9f cmd_test+0x417 (perf) > > builtin-test.c:825 > > 55a11d6155f5 run_builtin+0xd4 (perf) > > perf.c:349 > > 55a11d61588d handle_internal_command+0xdd (perf) > > perf.c:401 > > 55a11d6159e6 run_argv+0x35 (perf) > > perf.c:445 > > 55a11d615d2f main+0x2cb (perf) > > perf.c:553 > > 7fae3d233ca7 __libc_start_call_main+0x77 (libc.so.6) > > libc_start_call_main.h:58 > > 7fae3d233d64 __libc_start_main_impl+0x84 > > libc-start.c:360 (inlined) > > 55a11d565f80 _start+0x20 (perf) > > ??:0 > > ... > > ``` > > > > v3: Make the caller inline file and line number accurate in the libdw > > addr2line, rather than using the function's declared location. > > Fix reference counts in unwind-libdw. Add fixes tag for srcline > > inline printing. > > > > v2: Fix bias issue with libdwfl functions. Use cu_walk_functions_at > > from perf's dwarf-aux to fully walk inline functions. Add testing > > that inlined functions are shown in the perf script srcline > > callchain information. Add configurability as to which addr2line > > style to use. > > https://lore.kernel.org/lkml/20260110082647.1487574-1-irogers@google.com/ > > > > v1: https://lore.kernel.org/lkml/20251122093934.94971-1-irogers@google.com/ > > > > Ian Rogers (7): > > perf unwind-libdw: Fix invalid reference counts > > perf addr2line: Add a libdw implementation > > perf addr2line.c: Rename a2l_style to cmd_a2l_style > > perf srcline: Add configuration support for the addr2line style > > perf callchain: Fix srcline printing with inlines > > perf test workload: Add inlineloop test workload > > perf test: Test addr2line unwinding works with inline functions > > > > tools/perf/builtin-report.c | 10 ++ > > tools/perf/tests/builtin-test.c | 1 + > > tools/perf/tests/shell/addr2line_inlines.sh | 47 ++++++ > > tools/perf/tests/tests.h | 1 + > > tools/perf/tests/workloads/Build | 2 + > > tools/perf/tests/workloads/inlineloop.c | 52 +++++++ > > tools/perf/util/Build | 1 + > > tools/perf/util/addr2line.c | 20 +-- > > tools/perf/util/config.c | 4 + > > tools/perf/util/dso.c | 2 + > > tools/perf/util/dso.h | 11 ++ > > tools/perf/util/evsel_fprintf.c | 8 +- > > tools/perf/util/libdw.c | 153 ++++++++++++++++++++ > > tools/perf/util/libdw.h | 60 ++++++++ > > tools/perf/util/srcline.c | 116 ++++++++++++++- > > tools/perf/util/srcline.h | 3 + > > tools/perf/util/symbol_conf.h | 10 ++ > > tools/perf/util/unwind-libdw.c | 7 +- > > 18 files changed, 486 insertions(+), 22 deletions(-) > > create mode 100755 tools/perf/tests/shell/addr2line_inlines.sh > > create mode 100644 tools/perf/tests/workloads/inlineloop.c > > create mode 100644 tools/perf/util/libdw.c > > create mode 100644 tools/perf/util/libdw.h > > > > I don't see the differences to the other addr2line implementations > anymore, but only because it falls through to the old ones when libdw > fails now. > > For example when building Perf with LLVM it can't get the line in the > inlineloop workload, and there's still a few things in libc and other > system libraries it fails on. Hmm.. I wonder what the issue is. I was looking at the dwarf output from my gcc builds with llvm-dwarfdump. I wonder if LLVM builds are doing something to confuse libdw? I'll try to investigate. There are quite a few levels of libdw: there's the raw libdw, libdwfl (frontend to libdw) that does the parsing and tries to give things like nested debug scopes (libdwfl is the one needing addresses with a module bias rather than raw file offsets), and then there is the dwarf-aux.c that is in perf and is used by things like probe finding (I believe this doesn't need biases addresses). Anyway, with the biases there are things I can screw up (like in the v1 patch) but maybe the LLVM issue is just a libdw and dwarf-5 kind of thing. Maybe it is ARM specific :-/ > But I think it's fine because it doesn't give the wrong line anymore, it > just falls through to another working addr2line implementation. Just to confirm that with gcc builds it isn't failing now? ie it isn't just an addr2line implementation that falls through all the time? I was seeing things working/testing on x86 with gcc. > Reviewed-by: James Clark <james.clark@...aro.org> Thanks, Ian
Powered by blists - more mailing lists