Re: [PATCH v3 6/7] perf annotate: Support BPF JIT disassembly via genelf

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] JIT ELF generation uses host-native endianness and ELF class, breaking cross-platform analysis of BPF programs.
- [High] Mismatch between ELF text section address and DWARF debug line base address for JIT profiling.
--

commit 3c8720c4a004bb87cca5176252e00dcb2ade47e7
Author: Ian Rogers <irogers@google.com>

perf annotate: Support BPF JIT disassembly via genelf

For in-memory BPF DSOs (DSO_BINARY_TYPE__BPF_PROG_INFO), write the
JITted instruction buffer to a temporary ELF file on disk using the
existing genelf framework (jit_write_elf). Reroute disassembly to
this temporary ELF file, allowing objdump and libasm to disassemble it
natively. Clean up the temporary file afterward.

> diff --git a/tools/perf/util/genelf.c b/tools/perf/util/genelf.c
> index 14882def9704c..c3af040121eef 100644
> --- a/tools/perf/util/genelf.c
> +++ b/tools/perf/util/genelf.c
[ ... ]
> @@ -218,9 +218,9 @@ jit_write_elf(int fd, uint64_t load_addr __maybe_unused, const char *sym,
>  
>  	ehdr->e_ident[EI_DATA] = GEN_ELF_ENDIAN;
>  	ehdr->e_ident[EI_CLASS] = GEN_ELF_CLASS;
> -	ehdr->e_machine = GEN_ELF_ARCH;
> +	ehdr->e_machine = e_machine;

[Severity: High]
Does this hardcoded endianness and class break cross-platform trace analysis?

Since e_machine is now dynamically set, if a 64-bit x86 host analyzes a
32-bit or big-endian BPF trace (like ARM32 or s390x), wouldn't this generate a
corrupt ELF container (e.g., a 64-bit little-endian ELF claiming to be
EM_S390) and cause objdump to reject the file or decode with the wrong
endianness?

[ ... ]
> @@ -230,8 +230,8 @@ jit_write_elf(int fd, uint64_t load_addr __maybe_unused, const char *sym,
>  	phdr = elf_newphdr(e, 1);
>  	phdr[0].p_type = PT_LOAD;
>  	phdr[0].p_offset = GEN_ELF_TEXT_OFFSET;
> -	phdr[0].p_vaddr = GEN_ELF_TEXT_OFFSET;
> -	phdr[0].p_paddr = GEN_ELF_TEXT_OFFSET;
> +	phdr[0].p_vaddr = load_addr;
> +	phdr[0].p_paddr = load_addr;

[Severity: High]
Does changing the ELF virtual addresses to use load_addr break DWARF mapping?

In tools/perf/util/genelf_debug.c:jit_process_debug_info(), the code still
passes the hardcoded GEN_ELF_TEXT_OFFSET to add_debug_line():

	add_debug_line(dl, debug, nr_debug_entries, GEN_ELF_TEXT_OFFSET);

If the ELF is generated with load_addr but the DWARF .debug_line information
uses a base address of GEN_ELF_TEXT_OFFSET, will perf annotate and standard
debuggers fail to map source code lines to the disassembled instructions?

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