Re: [PATCH] perf build: Fix compiler errors with old capstone

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Defining CS_ARCH_RISCV as CS_ARCH_MAX causes incorrect architecture selection when dynamically loading newer Capstone versions.
--

commit c55db50010b415e5aa95bfca7819cc985aa51d2f
Author: Namhyung Kim <namhyung@kernel.org>

perf build: Fix compiler errors with old capstone

This commit fixes a build error on systems with Capstone versions older than
5 by defining missing RISC-V architecture and mode constants. It uses the
major version macro to conditionally define these symbols.

> diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c
> index 5ad537fea4360..dd7cd97d0a380 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    CS_ARCH_MAX

[Severity: High]
Does mapping CS_ARCH_RISCV to CS_ARCH_MAX cause ABI compatibility issues?

If perf is compiled against Capstone headers < 5, it will use the integer
value of CS_ARCH_MAX for CS_ARCH_RISCV. If the resulting binary is later run
on a system where libcapstone.so has been upgraded to version 5+, passing
this hardcoded value to cs_open() might silently initialize a completely
different architecture that was appended to the enum in V5 (such as WASM or
BPF).

Could this result in cs_open() succeeding but silently producing garbage
disassembly for RISC-V targets?

> +#define CS_MODE_RISCV32  1
> +#define CS_MODE_RISCV64  2
> +#define CS_MODE_RISCVC   4
> +#endif

[ ... ]

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