Wrong callq address displayed about bpftool HOT 5 OPEN

OK thank you.

So this is probably not implemented in bpftool itself (bpftool doesn't directly implement disassembling), it likely comes from the disassemblers we use.

Given than both library behave the same, I suspect they have a reason to do so, but it would be nice to understand the reason behind it and to make sure this is the behaviour we want (or to adjust it otherwise). I don't know if there's something we can do about it - I need to look into this into more details (won't be before next week at least).

Thanks for the report and tests!

from bpftool.

@qmonnet

It still showed call 0xffffffffc377aedc, which is the same wrong address.

My steps:

1. comment FEATURE_TESTS += llvm in src/Makefile
2. cd src; make

The stdout from make was:

$ make 
...                        libbfd: [ on  ]
...               clang-bpf-co-re: [ on  ]
...                          llvm: [ OFF ]
...                        libcap: [ OFF ]

3. run the same commands to check bpf_redirect call

$ s ./bpftool p d j tag 71cf8deecfc1bb77 opcode | grep 'redirect(' -A6
; return redirect(ifindex, flags);
15a1:	xor    %esi,%esi
	31 f6 
15a3:	mov    -0xc0(%rbp),%rax
	48 8b 85 40 ff ff ff 
15aa:	call   0xffffffffc377aedc
	e8 2d 99 77 c3 

from bpftool.

I think this is because we're missing the base address for the program when doing so.

Looking at your numbers:

$ python3 -c 'print(hex(0xffffffffc377992d + 5 + 0x15aa))'
0xffffffffc377aedc

We get the value printed by bpftool by taking the address in the opcodes, adding all offsets except for the base address for the program.

We should be able to retrieve this base address by parsing /proc/kallsyms in bpftool (we do it for other commands), although I'm not sure how we can plug that into the disassembler.

from bpftool.

Sorry I missed the version info, just downloaded the latest version from release page, and issue persists.

bpftool v7.2.0
using libbpf v1.2
features: llvm, skeletons

from bpftool.

Thanks! Could you please try and compare with the libbfd-based disassembler? I'd be curious to see whereas it does the same.

To do so you would need to compile with libbfd installed (usually shipped with binutils-dev), and to disable the llvm feature in the Makefile (Commenting FEATURE_TESTS += llvm should work).

from bpftool.