From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: bpf@vger.kernel.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v1 2/7] perf build: Add build support and capability for elfutils libasm
Date: Tue, 09 Jun 2026 05:28:42 +0000 [thread overview]
Message-ID: <20260609052843.B2EA91F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260609051759.405027-3-irogers@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `libasm` feature detection bypasses `NO_LIBELF=1` and `NO_LIBDW=1` build flags, forcing unwanted linkage of `libelf` and `libdw`.
- [Low] The libasm feature check unconditionally prints a confusing and false build warning when libasm is absent, resulting from a copy-paste error from the libcapstone check.
--
commit f7a26566fa9af4fab8dbd2f6062cf9924751f23c
Author: Ian Rogers <irogers@google.com>
perf build: Add build support and capability for elfutils libasm
Configure perf build system to utilize the libasm feature check
(supporting both static and dynamic builds) and export the config flags.
Add "libasm" capability detection to perf check.
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index 6e7b15fab2ecc..8b6c32392d618 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
[ ... ]
> @@ -1060,6 +1067,22 @@ ifndef NO_CAPSTONE
> endif
> endif
>
> +ifndef NO_LIBASM
> + $(call feature_check,libasm)
> + ifeq ($(feature-libasm), 1)
> + CFLAGS += -DHAVE_LIBASM_SUPPORT $(LIBASM_CFLAGS)
> + ifdef LIBASM_DLOPEN
> + CFLAGS += -DLIBASM_DLOPEN
> + else
> + LDFLAGS += $(LIBASM_LDFLAGS)
> + EXTLIBS += -lasm -ldw -lelf
[Severity: Medium]
Will this force linkage of libelf and libdw even when the user builds with
NO_LIBELF=1 or NO_LIBDW=1?
It appears NO_LIBASM isn't automatically set when NO_LIBELF=1 is used, unlike
other ELF-dependent libraries:
tools/perf/Makefile.config:
ifdef NO_LIBELF
NO_LIBDW := 1
NO_LIBUNWIND := 1
NO_LIBBPF := 1
NO_JVMTI := 1
else
Because of this, the libasm feature check will still run and unconditionally
append -lelf and -ldw to EXTLIBS, bypassing the user's explicit build
constraints.
> + endif
> + $(call detected,CONFIG_LIBASM)
> + else
> + msg := $(warning No libasm found, disables disasm engine support for 'perf script', please install elfutils-devel/elfutils-libelf-devel);
[Severity: Low]
Is this warning statement evaluating and printing during Makefile parsing
whenever libasm is absent?
In GNU Make, the $(warning) function is evaluated immediately as it is parsed.
This means users compiling perf without the optional libasm library might be
shown this warning even if they did not explicitly request libasm support.
Additionally, is the warning text accurate? It seems this might be a copy-paste
from the libcapstone check, as it claims missing libasm disables the
'perf script' disasm engine, but libasm is used for 'perf annotate' rather than
'perf script'.
> + endif
> +endif
> +
> ifdef EXTRA_TESTS
> $(call detected,CONFIG_EXTRA_TESTS)
> CFLAGS += -DHAVE_EXTRA_TESTS
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609051759.405027-1-irogers@google.com?part=2
next prev parent reply other threads:[~2026-06-09 5:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 5:17 [PATCH v1 0/7] perf annotate: Add elfutils libasm disassembler backend Ian Rogers
2026-06-09 5:17 ` [PATCH v1 1/7] tools build: Add feature check for elfutils libasm Ian Rogers
2026-06-09 5:28 ` sashiko-bot
2026-06-09 5:17 ` [PATCH v1 2/7] perf build: Add build support and capability " Ian Rogers
2026-06-09 5:28 ` sashiko-bot [this message]
2026-06-09 5:17 ` [PATCH v1 3/7] perf annotate: Implement elfutils libasm disassembler backend Ian Rogers
2026-06-09 5:30 ` sashiko-bot
2026-06-09 5:17 ` [PATCH v1 4/7] perf annotate: Add --disassembler command-line option Ian Rogers
2026-06-09 5:17 ` [PATCH v1 5/7] perf test: Enhance annotate test coverage and isolate config Ian Rogers
2026-06-09 5:28 ` sashiko-bot
2026-06-09 5:17 ` [PATCH v1 6/7] perf annotate: Support BPF JIT disassembly via genelf Ian Rogers
2026-06-09 5:33 ` sashiko-bot
2026-06-09 5:17 ` [PATCH v1 7/7] perf test: Add BPF JIT annotation test coverage for all disassemblers Ian Rogers
2026-06-09 5:36 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260609052843.B2EA91F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox