All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] perf build: Fix compiler errors with old capstone
@ 2026-07-06 23:48 Namhyung Kim
  2026-07-06 23:56 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Namhyung Kim @ 2026-07-06 23:48 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Ian Rogers, Jiri Olsa, Adrian Hunter, James Clark, Peter Zijlstra,
	Ingo Molnar, LKML, linux-perf-users

It seems RISCV was added in capstone version 5 (released Jul 2023).
Unfortunately they are enum constants so cannot check with #ifdef but
anyway we can define the symbols.  Let's do it using the version
number to avoid build errors.  It'll fail at runtime though.

  util/capstone.c: In function 'e_machine_to_capstone':
  util/capstone.c:186:25: error: 'CS_ARCH_RISCV' undeclared (first use in this function);
                                  did you mean 'CS_ARCH_SYSZ'?
    186 |                 *arch = CS_ARCH_RISCV;
        |                         ^~~~~~~~~~~~~
        |                         CS_ARCH_SYSZ
  util/capstone.c:186:25: note: each undeclared identifier is reported only once for each function it appears in

  util/capstone.c:187:34: error: 'CS_MODE_RISCV64' undeclared (first use in this function);
                                  did you mean 'CS_MODE_MIPS64'?
    187 |                 *mode |= (is64 ? CS_MODE_RISCV64 : CS_MODE_RISCV32) | CS_MODE_RISCVC;
        |                                  ^~~~~~~~~~~~~~~
        |                                  CS_MODE_MIPS64

Also note that capstone renamed CS_MODE_RISCVC to CS_MODE_RISCV_C which
would cause a different build failure on latest versions.  It's reported
in https://github.com/capstone-engine/capstone/issues/2977 so I think
they will add compatibility layer to prevent the error.

Fixes: 12c4737f55f2 ("perf capstone: Determine architecture from e_machine")
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
v2 changes)
 * use the actual constant for CS_ARCH_RISCV  (Sashiko)

 tools/perf/util/capstone.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c
index 5ad537fea4360e31..0247142a77ba3c25 100644
--- a/tools/perf/util/capstone.c
+++ b/tools/perf/util/capstone.c
@@ -24,6 +24,13 @@
 #include "symbol.h"
 #include "thread.h"
 
+#if CS_VERSION_MAJOR < 5
+#define CS_ARCH_RISCV    15
+#define CS_MODE_RISCV32  1
+#define CS_MODE_RISCV64  2
+#define CS_MODE_RISCVC   4
+#endif
+
 #ifdef LIBCAPSTONE_DLOPEN
 static void *perf_cs_dll_handle(void)
 {
-- 
2.55.0.rc2.803.g1fd1e6609c-goog


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] perf build: Fix compiler errors with old capstone
  2026-07-06 23:48 [PATCH v2] perf build: Fix compiler errors with old capstone Namhyung Kim
@ 2026-07-06 23:56 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-07-06 23:56 UTC (permalink / raw)
  To: Namhyung Kim; +Cc: linux-perf-users

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Leaked `struct map *` reference in `print_capstone_detail` due to missing `map__put()`.
--

--- Patch [1]: [PATCH v2] perf build: Fix compiler errors with old capstone ---
commit 290412dd8be8c32690d86ead2197a90f8b8eb074
Author: Namhyung Kim <namhyung@kernel.org>

perf build: Fix compiler errors with old capstone

This commit fixes build failures on older capstone versions (prior to v5) by
defining missing RISC-V architectural and mode constants.

> diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c
> index 5ad537fea4360..0247142a77ba3 100644
> --- a/tools/perf/util/capstone.c
> +++ b/tools/perf/util/capstone.c
> @@ -24,6 +24,13 @@
>  #include "symbol.h"
>  #include "thread.h"
>  
> +#if CS_VERSION_MAJOR < 5
> +#define CS_ARCH_RISCV    15
> +#define CS_MODE_RISCV32  1
> +#define CS_MODE_RISCV64  2
> +#define CS_MODE_RISCVC   4
> +#endif

[ ... ]

Later in tools/perf/util/capstone.c:print_capstone_detail():

> 		if (dso__kernel(map__dso(map))) {
> 			/*
> 			 * The kernel maps can be split into sections, let's
> 			 * find the map first and the search the symbol.
> 			 */
> 			map = maps__find(map__kmaps(map), addr);

[Severity: High]
This isn't a bug introduced by this patch, but does this code leak the map
reference?

When disassembling instructions with X86 memory operands using RIP-relative
addressing, maps__find() returns a new reference to the kernel section map.
Since this new reference is assigned to the local map variable, is there a
missing map__put() before the function returns or the loop continues? This
might lead to a resource leak and reference count imbalance.

> 			if (map == NULL)
> 				continue;
> 		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706234836.815254-1-namhyung@kernel.org?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-07-06 23:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-06 23:48 [PATCH v2] perf build: Fix compiler errors with old capstone Namhyung Kim
2026-07-06 23:56 ` sashiko-bot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.