Re: [PATCH v3 1/4] perf symbol: Fix symbol loading from libbfd

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Wed, Oct 14, 2026 at 07:17:39PM -0300, Arnaldo Carvalho de Melo wrote:
> On Tue, Oct 13, 2026 at 02:02:15PM -0700, Namhyung Kim wrote:
> > On Tue, Oct 13, 2026 at 03:35:24PM -0300, Arnaldo Carvalho de Melo wrote:
> > > On Mon, Oct 12, 2026 at 04:59:34PM -0700, Namhyung Kim wrote:
> > > > The dso__load() should return a positive number (number of symbols
> > > > loaded) when it succeded to load symbols.  But dso__load_bfd_symbols()
> > > > only returns 0 and it's hard to check if it actually loaded symbols or
> > > > not.  Let's return the value of dso__has_symbol() and check it in
> > > > dso__load() so that it can return 1 for success.
> > > > 
> > > > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > > > Closes: https://lore.kernel.org/r/sashiko-outbox-162540@kernel.org
> > > > Fixes: eac9a4342e5447cad ("perf symbols: Try reading the symbol table with libbfd")
> > > > Reviewed-by: Ian Rogers <irogers@google.com>
> > > > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > > 
> > > Thanks, applied to perf-tools-next, for v7.4.
> > 
> > Thanks Arnaldo!
> > 
> > As you may know, this is from my other series on cleaning up symtab and
> > binary types.  I'd like to land it as well so that I can continue
> > working on the related issues.  There are some Sashiko feedback left,
> > but I think they are either pre-existing bugs or known issues.
> 
> Right, its now at tmp.perf-tools-next, while I test build in my
> container set, will push it to perf-tools-next next.

Building it with CC=clang I get:

  LD      /tmp/build/perf-tools-next/tests/perf-test-in.o
util/dso.c:942:7: error: mutex '_dso__data_open_lock' is not held on every path through here [-Werror,-Wthread-safety-analysis]
  942 |                 if (dso__data_open_cnt) {
      |                     ^
util/dso.c:940:4: note: mutex acquired here
  940 |                         mutex_lock(dso__data_open_lock());
      |                         ^
util/dso.c:942:7: error: reading variable 'dso__data_open_cnt' requires holding mutex '_dso__data_open_lock'   CC      /tmp/build/perf-tools-next/util/maps.o
[-Werror,-Wthread-safety-analysis]
  942 |                 if (dso__data_open_cnt) {
      |                     ^
util/dso.c:943:4: error: calling function 'close_first_dso' requires holding mutex '_dso__data_open_lock' exclusively [-Werror,-Wthread-safety-analysis]
  943 |                         close_first_dso();
      |                         ^
util/dso.c:949:3: error: releasing mutex '_dso__data_open_lock' that was not held [-Werror,-Wthread-safety-analysis]
  949 |                 mutex_unlock(dso__data_open_lock());
      |                 ^
4 errors generated.
make[4]: *** [/home/acme/git/perf-tools-next/tools/build/Makefile.build:95: /tmp/build/perf-tools-next/util/dso.o] Error 1
  CC      /tmp/build/perf-tools-next/util/thread.o

Bisected to:

⬢ [acme@tb-phoenix2-perf perf-tools-next]$ git bisect good
3759ca226d57d06c4c52a1e64890faf58a29ebf1 is the first 'bad' commit
commit 3759ca226d57d06c4c52a1e64890faf58a29ebf1
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Oct 13 10:21:51 2026 -0700

    perf tools: Factor out dso__find_binary_type()

    Separate out the logic to detect binary type of a DSO.  It checks if
    the candidate file contains ".text" section.  There could be data-only
    DSOs but as our use cases focus on the code (perf annotate or intel
    PT), we can ignore them for now.

    But it also can fail due to open file limit.  Handle the case by
    retrying with _dso__data_open_lock.

    Introduce bintype_searched flag and it accessors to prevent repeated
    (failed) search.

    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

 tools/perf/util/dso.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------
 tools/perf/util/dso.h |  13 +++++++++++++
 2 files changed, 139 insertions(+), 12 deletions(-)
⬢ [acme@tb-phoenix2-perf perf-tools-next]$