On 2024/10/30 22:56, Stanislav Fomichev wrote: > On 10/30, Leon Hwang wrote: >> >> >> On 2024/10/30 17:47, Leon Hwang wrote: >>> From: Leon Hwang <leon.hwang@xxxxxxxxx> >>> >>> This patch addresses the bpftool issue "Wrong callq address displayed"[0]. >>> >>> The issue stemmed from an incorrect program counter (PC) value used during >>> disassembly with LLVM or libbfd. To calculate the correct address for >>> relative calls, the PC argument must reflect the actual address in the >>> kernel. >>> >>> [0] https://github.com/libbpf/bpftool/issues/109 >>> >>> Fixes: e1947c750ffe ("bpftool: Refactor disassembler for JIT-ed programs") >>> Signed-off-by: Leon Hwang <leon.hwang@xxxxxxxxx> >>> --- >>> tools/bpf/bpftool/jit_disasm.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/tools/bpf/bpftool/jit_disasm.c b/tools/bpf/bpftool/jit_disasm.c >>> index 7b8d9ec89ebd3..fe8fabba4b05f 100644 >>> --- a/tools/bpf/bpftool/jit_disasm.c >>> +++ b/tools/bpf/bpftool/jit_disasm.c >>> @@ -114,8 +114,7 @@ disassemble_insn(disasm_ctx_t *ctx, unsigned char *image, ssize_t len, int pc) >> >> It seems we should update the type of pc from int to __u64, as the type >> of func_ksym is __u64 and the type of pc argument in disassemble >> function of LLVM and libbfd is __u64 for 64 bit arch. > > I'm assuming u32 is fine as long as the prog size is under 4G? > It works well with int. So it's unnecessary to update its type. >>> char buf[256]; >>> int count; >>> > > [..] > >>> - count = LLVMDisasmInstruction(*ctx, image + pc, len - pc, pc, >>> - buf, sizeof(buf)); >>> + count = LLVMDisasmInstruction(*ctx, image, len, pc, buf, sizeof(buf)); > > For my understanding, another way to fix it would be: > count = LLVMDisasmInstruction(*ctx, image + pc, len - pc, 0, > buf, sizeof(buf)); > > IOW, in the original code, using 0 instead of pc should fix it as well? > Or am I missing something? No. It does not work when using 0. I just tried it. I think it's because LLVM is unable to infer the actual address of the disassembling insn when we do not provide func_ksym to LLVM. Thanks, Leon
