Re: [PATCH v8 03/17] perf capstone: Determine architecture from e_machine

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Hardcoded endianness in e_machine_to_capstone() breaks disassembly for bi-endian architectures.
- [High] thread__e_machine() fallback to EM_HOST breaks cross-architecture disassembly for kernel code and BPF programs.
--

commit a3ff746537f2f9677ae9d6427555ff27588e61a4
Author: Ian Rogers <irogers@google.com>
perf capstone: Determine architecture from e_machine

This commit refactors capstone initialization to use the e_machine value
from the ELF header instead of the architecture string, adding support
for MIPS and RISCV translations.

Note: The format of this review has been altered to provide a free-form
summary of the findings without directly quoting the patch code, due to
recitation restrictions.

The new e_machine_to_capstone() function hardcodes CS_MODE_BIG_ENDIAN for
EM_PPC, EM_PPC64, and EM_MIPS, and implicitly assumes little-endian for
EM_AARCH64 and EM_ARM.

Does this approach break disassembly for bi-endian architectures?

Linux fully supports variants like ppc64le, mipsel, armeb, and aarch64_be
under these same e_machine IDs. Because the initialization now succeeds
with the hardcoded endianness rather than returning -1, it actively bypasses
the functional fallback to objdump. Since objdump natively reads EI_DATA
from the ELF header to determine the correct endianness, skipping it leaves
these architectures with incorrect disassembly output.

Could we read EI_DATA alongside e_machine to set the endianness mode correctly?

Additionally, the updated code replaces machine__normalized_is() with
thread__e_machine() to determine the target architecture.

Will this break cross-architecture disassembly for kernel code and BPF
programs?

Previously, machine__normalized_is() correctly determined the architecture
from machine->env->arch, which is populated by the perf.data file header.
The new approach searches DSOs and falls back to dso__e_machine(), which
is hardcoded to return EM_HOST (the compile-time host architecture of the
perf binary) for kernel components like DSO_BINARY_TYPE__KALLSYMS,
DSO_BINARY_TYPE__VMLINUX, and DSO_BINARY_TYPE__BPF_PROG_INFO.

If a user performs cross-architecture analysis, such as analyzing an ARM64
perf.data file on an x86_64 host, won't thread__e_machine() return
EM_X86_64? This would cause Capstone to decode ARM64 kernel or JIT
instructions as x86_64 instructions.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260502065935.291960-1-irogers@google.com?part=3