Re: Problem with perf report --gtk

[Guilherme Amadio <amadio@gentoo.org>]

On Wed, Sep 10, 2025 at 09:45:35AM -0700, Ian Rogers wrote:
> On Tue, Sep 9, 2025 at 6:37 AM Guilherme Amadio <amadio@gentoo.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@gentoo.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?

Dear Ian,

I don't see any hashmap symbol as part of my own perf executable:

perf $ pwd && ./perf version
/home/amadio/src/linux/tools/perf
perf version 6.16.6.g1037d3a33ba6
perf $ nm -D ./perf | grep hashmap
perf $ 
I compiled perf with:

$ make -B -j16 V=1 WERROR=0 NO_SHELLCHECK=1 GTK2=1

Cheers,
-Guilherme