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

[Namhyung Kim <namhyung@kernel.org>]

On Wed, Jul 01, 2026 at 06:38:29PM +0000, sashiko-bot@kernel.org wrote:
> 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?

Ok, I'll use the actual number from v5 then.

Thanks,
Namhyung

> 
> > +#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