Problem with perf report --gtk

Problem with perf report --gtk

[Guilherme Amadio]

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/.

Best regards,
-Guilherme

Re: Problem with perf report --gtk

[Ian Rogers]

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)

Thanks,
Ian

Re: Problem with perf report --gtk

[Guilherme Amadio]

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.

Best regards,
-Guilherme

Re: Problem with perf report --gtk

[Ian Rogers]

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?

Thanks,
Ian

Re: Problem with perf report --gtk

[Guilherme Amadio]

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

Re: Problem with perf report --gtk

[Ian Rogers]

On Fri, Sep 12, 2025 at 4:49 AM Guilherme Amadio <amadio@gentoo.org> wrote:
>
> 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

Thanks Guilherme, no good clue why that is different for me. I came up
with this patch to try to include all the symbols from the static
libraries with --whole-archive:
```
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index e2150acc2c13..56127c073f47 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -807,7 +807,9 @@ $(GTK_IN): FORCE prepare
       $(Q)$(MAKE) $(build)=gtk

$(OUTPUT)libperf-gtk.so: $(GTK_IN) $(PERFLIBS)
-       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) $(filter %.o,$^) $(GTK_LIBS)
+       $(QUIET_LINK)$(CC) -o $@ -shared $(LDFLAGS) \
+               -Wl,--whole-archive $(filter %.a,$^) -Wl,--no-whole-archive \
+               $(filter %.o,$^) $(GTK_LIBS)

$(OUTPUT)common-cmds.h: util/generate-cmdlist.sh command-list.txt

diff --git a/tools/perf/ui/gtk/Build b/tools/perf/ui/gtk/Build
index eef708c502f4..f106d5c884ab 100644
--- a/tools/perf/ui/gtk/Build
+++ b/tools/perf/ui/gtk/Build
@@ -7,8 +7,3 @@ gtk-y += util.o
gtk-y += helpline.o
gtk-y += progress.o
gtk-y += annotate.o
-gtk-y += zalloc.o
-
-$(OUTPUT)ui/gtk/zalloc.o: ../lib/zalloc.c FORCE
-       $(call rule_mkdir)
-       $(call if_changed_dep,cc_o_c)
```
I needed to remove zalloc.o to avoid duplicate symbols. With this
patch I no longer see any hashmap undefined symbols:
```
$ nm /tmp/perf/libperf-gtk.so |grep hashmap
00000000000cc2ca t hashmap_add_entry
00000000000cc4e7 t hashmap__capacity
00000000000cc3dc t hashmap__clear
00000000000cc2f3 t hashmap_del_entry
00000000000cc9fd t hashmap_delete
00000000000cc966 t hashmap_find
00000000000cc6aa t hashmap_find_entry
00000000000cc49c t hashmap__free
00000000000cc54c t hashmap_grow
00000000000cc31d t hashmap__init
00000000000cc773 t hashmap_insert
00000000000cc4f9 t hashmap_needs_to_grow
00000000000cc387 t hashmap__new
00000000000cc4d5 t hashmap__size
00000000001e42b0 t hwmon_pmu__event_hashmap_equal
00000000001e4280 t hwmon_pmu__event_hashmap_hash
$ nm -D /tmp/perf/libperf-gtk.so |grep hashmap
$
```
I briefly tested `perf report --gtk` and under gdb I see the symbol
twice, once in perf and once in libperf-gtk.so. I think this should
resolve your issue, wdyt?

Thanks,
Ian