Re: [PATCH v4 01/23] perf capstone: Fix arm64 jump/adrp disassembly mismatch with objdump
Shuai Xue <[email protected]>
| Newsgroups | dev.linux.lists.llvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users |
|---|---|
| Message-ID | <[email protected]> |
On 8/11/26 10:27 AM, Tengda Wu wrote: > Hi Shuai, thank you for your time. > > On 2026/8/10 21:08, Shuai Xue wrote: >> >> >> On 8/8/26 8:23 PM, Tengda Wu wrote: >>> The jump and adrp instructions parsed by libcapstone currently lack >>> symbolic representation and use a '#' prefix for addresses. This >>> format is inconsistent with objdump's output, which causes subsequent >>> parsing in jump__parse() and arm64_mov__parse() to fail. >>> >>> Example mismatch: >>> Current: b #0xffff8000800114c8 >>> Fix: b ffff8000800114c8 <el0t_64_sync+0x108> >>> >>> Current: adrp x18, #0xffff800081f5f000 >>> Fix: adrp x18, ffff800081f5f000 <this_cpu_vector> >>> >>> Fix this by implementing extended formatting for these arm64 >>> instructions during symbol__disassemble_capstone(). This ensures >>> the output matches objdump's expected style, including the raw >>> address and the associated <symbol+offset> suffix. >>> >>> Signed-off-by: Tengda Wu <[email protected]> >>> --- >>> tools/perf/util/capstone.c | 136 +++++++++++++++++++++++++++++++++---- >>> tools/perf/util/disasm.c | 5 ++ >>> tools/perf/util/disasm.h | 1 + >>> 3 files changed, 130 insertions(+), 12 deletions(-) >>> >>> diff --git a/tools/perf/util/capstone.c b/tools/perf/util/capstone.c >>> index 74213daf8786..fb8a2bc5558f 100644 >>> --- a/tools/perf/util/capstone.c >>> +++ b/tools/perf/util/capstone.c >>> @@ -3,6 +3,7 @@ >>> #include <errno.h> >>> #include <inttypes.h> >>> +#include <stdlib.h> >>> #include <string.h> >>> #include <dlfcn.h> >>> @@ -31,6 +32,10 @@ >>> #define CS_MODE_RISCVC 4 >>> #endif >>> +#if CS_VERSION_MAJOR < 4 >>> +#define ARM64_GRP_BRANCH_RELATIVE 7 >> >> Please add a comment explaining where '7' comes from >> (CS_GRP_BRANCH_RELATIVE in capstone v3), otherwise it reads like an >> arbitrary magic number. >> > > Um, this was done following Namhyung's approach. That said, adding a > comment would certainly make this definition clearer -- will add it. > > Also, I couldn't find CS_GRP_BRANCH_RELATIVE in v3. From what I can see, > it was originally introduced in v4, together with ARM64_GRP_BRANCH_RELATIVE > (see https://github.com/capstone-engine/capstone/commit/a09a81813c83). > So the comment might look something like this: > > #define ARM64_GRP_BRANCH_RELATIVE 7 /* = CS_GRP_BRANCH_RELATIVE */ > > Is this acceptable? > LGTM. Thanks. Shuai