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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Objdump fails to disassemble the temporary BPF ELF file because of an address range mismatch between the ELF file's hardcoded text section and objdump's `--start-address` boundary.
--

commit 515b53823b20255d2b911e2440f76dd5f76eaf39
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/disasm.c b/tools/perf/util/disasm.c
> index 42af3603fdffd..0648afd1b5f31 100644
> --- a/tools/perf/util/disasm.c
> +++ b/tools/perf/util/disasm.c
[ ... ]
> +#ifdef HAVE_LIBELF_SUPPORT
> +#include <unistd.h>
> +#include "dwarf-regs.h"
> +static int symbol__create_bpf_temp_elf(const char *filename, struct symbol *sym,
> +				       struct annotate_args *args,
> +				       char *tmp_elf, size_t tmp_elf_sz)
> +{
[ ... ]
> +	if (tmp_fd >= 0) {
> +		uint16_t e_machine = args->arch ? args->arch->id.e_machine : EM_HOST;
> +
> +		if (jit_write_elf(tmp_fd, e_machine, map__rip_2objdump(map, sym->start),
> +				  sym->name, buf, buf_len,
> +				  NULL, 0, NULL, 0, 0) == 0) {

[Severity: Medium]
Will this cause objdump to misalign or truncate the disassembly?

When symbol__create_bpf_temp_elf() calls jit_write_elf(), it passes
map__rip_2objdump(map, sym->start) as the load_addr argument, but
jit_write_elf() explicitly ignores this argument:

tools/perf/util/genelf.c:jit_write_elf() {
    ...
    int
    jit_write_elf(int fd, uint16_t e_machine, uint64_t load_addr __maybe_unused, const char *sym,
    ...
}

Instead, jit_write_elf() hardcodes the .text section VMA to
GEN_ELF_TEXT_OFFSET (typically 128 bytes).

Later, when symbol__disassemble_objdump() invokes objdump, it uses
--start-address and --stop-address derived from the symbol's start and end
addresses:

tools/perf/util/disasm.c:symbol__disassemble_objdump() {
    ...
	err = asprintf(&command,
		 "%s %s%s --start-address=0x%016" PRIx64
		 " --stop-address=0x%016" PRIx64
    ...
}

For BPF DSOs, these addresses typically map to the range [0, csize]. However,
the actual instructions inside the generated ELF are placed at
[GEN_ELF_TEXT_OFFSET, GEN_ELF_TEXT_OFFSET + csize].

If the BPF program is smaller than GEN_ELF_TEXT_OFFSET, does objdump end up
outputting nothing? If it is larger, could this result in objdump reading
misaligned and truncated instructions that no longer match the performance
samples?

As a side note, it appears that any test added later in the series might
silently pass if it only blindly greps for offsets in objdump's output, which
would mask this offset and truncation corruption.

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