Message-ID: <CAP-5=fX-GG_pUH+1Eak8dsoTdNh=vRU+00scBxbRt7EhXZosiw@mail.gmail.com>
Date: Wed, 10 Sep 2025 09:45:35 -0700
From: Ian Rogers <irogers@...gle.com>
To: Guilherme Amadio <amadio@...too.org>
Cc: acme@...nel.org, namhyung@...nel.org, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org
Subject: Re: Problem with perf report --gtk

On Tue, Sep 9, 2025 at 6:37 AM Guilherme Amadio <amadio@...too.org> wrote:
>
> On Tue, Sep 09, 2025 at 06:04:42AM -0700, Ian Rogers wrote:
> > On Tue, Sep 9, 2025 at 3:33 AM Guilherme Amadio <amadio@...too.org> wrote:
> > >
> > > Hi Arnaldo, Namhyung,
> > >
> > > Since sometime we have a bug in Gentoo's bugzilla about perf report --gtk not
> > > working¹: https://bugs.gentoo.org/937869
> > >
> > > I know this feature is not used very much, but I thought I'd report in
> > > any case. The problem is easily reproducible as shown below:
> > >
> > >
> > > $ perf record -a -g -- sleep 1
> > > [ perf record: Woken up 1 times to write data ]
> > > [ perf record: Captured and wrote 1.818 MB perf.data (6648 samples) ]
> > > $ LD_DEBUG=symbols perf report --gtk 2>&1 | grep '(fatal)'
> > >     288067:     /usr/libexec/perf-core/libperf-gtk.so: error: symbol lookup error: undefined symbol: hashmap_find (fatal)
> > > $ perf report --gtk
> > > GTK browser requested but could not find libperf-gtk.so
> > >
> > > I tried this with perf 6.16, but this bug seems to have been there since
> > > at least 6.12.
> > >
> > > Please let me know if it's better to file problems at https://bugzilla.kernel.org/.
> >
> > Thanks for letting us know Guilherme! I suspect I broke things when
> > trying to fix python things. The code linking libperf-gtk.so is:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next#n809
> > The hashmap symbols are part of the perf-util library:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/Build?h=perf-tools-next#n197
> > So maybe there needs to be a libbpf -lbpf for your case? Alternatively
> > we may need to reorder the libraries here:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next#n464
> > like:
> > PERFLIBS += $(LIBPERF_BENCH) $(LIBPERF_TEST) $(LIBPERF_UI) $(LIBPERF_UTIL)
> > becomes:
> > PERFLIBS += $(LIBPERF_BENCH) $(LIBPERF_TEST) $(LIBPERF_UTIL) $(LIBPERF_UI)
>
> Thank you for the suggestion, but just changing the order of linking or
> linking libbpf doesn't seem to fix the issue. I still see:
>
> $ nm -D libperf-gtk.so | grep hashmap
>                  U hashmap_find
>
> at the end of the build. The function is in util/hashmap.c, so the
> problem might be more involved than just the linking order.

Thanks Guilherme! I was able to reproduce the "nm -D" output. Adding
"-z defs" to the "$(OUTPUT)libperf-gtk.so" also fails for that symbol,
it fails for many more. Even though the symbol is undefined "perf
reprt --gtk" works for me. Attaching gdb I see that the symbol is in
the perf executable itself. I tried the following change:
```
 $(OUTPUT)libperf-gtk.so: $(GTK_IN) $(PERFLIBS)
-       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter %.o,$^) $(GTK_LIBS)
+       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter %.o,$^)
$(filter %libperf-util.a,$^) $(GTK_LIBS)
```
or
```
 $(OUTPUT)libperf-gtk.so: $(GTK_IN) $(PERFLIBS)
-       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter %.o,$^) $(GTK_LIBS)
+       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter
%libperf-util.a,$^) $(filter %.o,$^) $(GTK_LIBS)
```
but the nm output shows either the same or more undefined symbols, not less.

I'm wondering if perhaps the hashmap_find symbol is being stripped
from the perf executable. Maybe it is an LTO or stripping related
thing?

Thanks,
Ian

Powered by blists - more mailing lists