Re: [PATCH bpf-next 6/7] bpftool: Add LLVM as default library for disassembling JIT-ed programs

[Quentin Monnet <quentin@isovalent.com>]

On 07/09/2022 19:02, Yonghong Song wrote:
> 
> 
> On 9/7/22 9:33 AM, Quentin Monnet wrote:
>> On 07/09/2022 17:10, Alexei Starovoitov wrote:
>>> On Wed, Sep 7, 2022 at 7:20 AM Quentin Monnet <quentin@isovalent.com>
>>> wrote:
>>>>
>>>> On 07/09/2022 00:46, Alexei Starovoitov wrote:
>>>>> On Tue, Sep 6, 2022 at 6:36 AM Quentin Monnet
>>>>> <quentin@isovalent.com> wrote:

>>>>>>      # bpftool prog dump jited id 56
>>>>>>      bpf_prog_6deef7357e7b4530:
>>>>>>         0:   nopl    (%rax,%rax)
>>>>>>         5:   nop
>>>>>>         7:   pushq   %rbp
>>>>>>         8:   movq    %rsp, %rbp
>>>>>>         b:   pushq   %rbx
>>>>>>         c:   pushq   %r13
>>>>>>         e:   pushq   %r14
>>>>>>        10:   movq    %rdi, %rbx
>>>>>>        13:   movzwq  176(%rbx), %r13
>>>>>>        1b:   xorl    %r14d, %r14d
>>>>>>        1e:   orl     $2, %r14d
>>>>>>        22:   movl    $1, %eax
>>>>>>        27:   cmpq    $2, %r14
>>>>>>        2b:   jne     2
>>>>>>        2d:   xorl    %eax, %eax
>>>>>>        2f:   popq    %r14
>>>>>
>>>>> If I'm reading the asm correctly the difference is significant.
>>>>> jne 0x2f was an absolute address and jmps were easy
>>>>> to follow.
>>>>> While in llvm disasm it's 'jne 2' ?! What is 2 ?
>>>>> 2 bytes from the next insn of 0x2d ?
>>>>
>>>> Yes, that's it. Apparently, this is how the operand is encoded, and
>>>> libbfd does the translation to the absolute address:
>>>>
>>>>      # bpftool prog dump jited id 7868 opcodes
>>>>      [...]
>>>>        2b:   jne    0x000000000000002f
>>>>              75 02
>>>>      [...]
>>>>
>>>> The same difference is observable between objdump and llvm-objdump
>>>> on an
>>>> x86-64 binary for example, although they usually have labels to
>>>> refer to
>>>> ("jne     -22 <_obstack_memory_used+0x7d0>"), making the navigation
>>>> easier. The only mention I could find of that difference is a report
>>>> from 2013 [0].
>>>>
>>>> [0] https://discourse.llvm.org/t/llvm-objdump-disassembling-jmp/29584/2
>>>>
>>>>> That is super hard to read.
>>>>> Is there a way to tune/configure llvm disasm?
>>>>
>>>> There's a function and some options to tune it, but I tried them and
>>>> none applies to converting the jump operands.
>>>>
>>>>      int LLVMSetDisasmOptions(LLVMDisasmContextRef DC, uint64_t
>>>> Options);
>>>>
>>>>      /* The option to produce marked up assembly. */
>>>>      #define LLVMDisassembler_Option_UseMarkup 1
>>>>      /* The option to print immediates as hex. */
>>>>      #define LLVMDisassembler_Option_PrintImmHex 2
>>>>      /* The option use the other assembler printer variant */
>>>>      #define LLVMDisassembler_Option_AsmPrinterVariant 4
>>>>      /* The option to set comment on instructions */
>>>>      #define LLVMDisassembler_Option_SetInstrComments 8
>>>>      /* The option to print latency information alongside
>>>> instructions */
>>>>      #define LLVMDisassembler_Option_PrintLatency 16
>>>>
>>>> I found that LLVMDisassembler_Option_AsmPrinterVariant read better,
>>>> although in my patch I kept the default output which looked closer to
>>>> the existing from libbfd. Here's what the option produces:
>>>>
>>>>      bpf_prog_6deef7357e7b4530:
>>>>         0:   nop     dword ptr [rax + rax]
>>>>         5:   nop
>>>>         7:   push    rbp
>>>>         8:   mov     rbp, rsp
>>>>         b:   push    rbx
>>>>         c:   push    r13
>>>>         e:   push    r14
>>>>        10:   mov     rbx, rdi
>>>>        13:   movzx   r13, word ptr [rbx + 180]
>>>>        1b:   xor     r14d, r14d
>>>>        1e:   or      r14d, 2
>>>>        22:   mov     eax, 1
>>>>        27:   cmp     r14, 2
>>>>        2b:   jne     2
>>>>        2d:   xor     eax, eax
>>>>        2f:   pop     r14
>>>>        31:   pop     r13
>>>>        33:   pop     rbx
>>>>        34:   leave
>>>>        35:   re
>>>>
>>>> But the jne operand remains a '2'. I'm not aware of any option to
>>>> change
>>>> it in LLVM's disassembler :(.
>>>
>>> Hmm. llvm-objdump -d test_maps
>>> looks fine:
>>>    41bfcb: e8 6f f7 ff ff                   callq    0x41b73f
>>> <find_extern_btf_id>
>>>
>>> the must be something llvm disasm is missing when you feed raw bytes
>>> into it.
>>> Please keep investigating. In this form I'm afraid it's no go.
>>
>> OK, I'll keep looking
> 
> Quentin, if eventually there is no existing solution for this problem,
> we could improve llvm API to encode branch target in more
> easy-to-understand form.
> 

TL;DR: I figured it out, with no LLVM fix required. I'll send a v2.

---
The details:
In my previous example, I ran on Ubuntu 20.04 with llvm-objdump v10.
Looking at just the v11 with the same command, I get the relative
addresses like in Alexei's output:

    $ llvm-objdump-10 -d /usr/bin/grep | grep -m1 jne
        4f20: 0f 85 e7 0b 00 00             jne     3047 <.text+0xddd>

    $ llvm-objdump-11 -d /usr/bin/grep | grep -m1 jne
        4f20: 0f 85 e7 0b 00 00             jne     0x5b0d <.text+0xddd>

    $ printf '%#x\n' $((0x4f20 + 3047 + 6))
    0x5b0d

The change was introduced between the two versions by the following commits:

    5fad05e80dd0 ("[MCInstPrinter] Pass `Address` parameter to
        MCOI::OPERAND_PCREL typed operands. NFC")
    https://reviews.llvm.org/D76574

    87de9a0786d9 ("[X86InstPrinter] Change printPCRelImm to print the
        target address in hexadecimal form")
    https://reviews.llvm.org/D76580

The first one in particular introduces a PrintBranchImmAsAddress
variable in the MCInstPrinter, and makes llvm-obdump call
"setPrintBranchImmAsAddress(true);".

Now, this function is not exposed to the C interface, llvm-c, that
bpftool would use. Instead, it's available through the more
comprehensive C++ interface that llvm-objdump relies on. I've tried to
replicate these two commits in the MCDisassembler that llvm-c interfaces
with, and succeeded.

But while looking at unit tests to extend it with the relevant checks, I
realised that the existing test would already expect an address instead
of an operand [0]. Turns out that the symbolLookupCallback() callback
defined in the test and passed when creating the disassembler ends up
changing the display so we get the operands as addresses, as we want.

[0]
https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/llvm/unittests/MC/Disassembler.cpp#L64
---

I validated that this works in bpftool too, and will send v2 with that
change.

P.S. Thank you Niklas for testing!