BPF List
 help / color / mirror / Atom feed
From: Quentin Monnet <quentin@isovalent.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@kernel.org>,
	"Stanislav Fomichev" <sdf@google.com>,
	"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
	bpf <bpf@vger.kernel.org>,
	"Niklas Söderlund" <niklas.soderlund@corigine.com>,
	"Simon Horman" <simon.horman@corigine.com>
Subject: Re: [PATCH bpf-next v3 6/8] bpftool: Add LLVM as default library for disassembling JIT-ed programs
Date: Mon, 24 Oct 2022 12:05:25 +0100	[thread overview]
Message-ID: <1dc2c77a-2dea-25a4-fa64-b65460c7f1cb@isovalent.com> (raw)
In-Reply-To: <CAADnVQKHk88YFcTE55GXu7HwQkTb0TGNpnrB8Ec7PVZy9uVhOw@mail.gmail.com>

2022-10-20 10:49 UTC-0700 ~ Alexei Starovoitov
<alexei.starovoitov@gmail.com>
> On Thu, Oct 20, 2022 at 5:37 AM Quentin Monnet <quentin@isovalent.com> wrote:
>>
>> +
>> +/* This callback to set the ref_type is necessary to have the LLVM disassembler
>> + * print PC-relative addresses instead of byte offsets for branch instruction
>> + * targets.
>> + */
>> +static const char *
>> +symbol_lookup_callback(__maybe_unused void *disasm_info,
>> +                      __maybe_unused uint64_t ref_value,
>> +                      uint64_t *ref_type, __maybe_unused uint64_t ref_PC,
>> +                      __maybe_unused const char **ref_name)
>> +{
>> +       *ref_type = LLVMDisassembler_ReferenceType_InOut_None;
>> +       return NULL;
>> +}
> 
> Could you give an example before/after for asm
> that contains 'call foo' instructions?
> I'm not sure that above InOut_None will not break
> symbolization.

Hi Alexei, I ran a quick test and it doesn't seem we lose any
information. Building from:

	#include <linux/bpf.h>
	#include "bpf_helper_defs.h"

	#define SEC(name) __attribute__((section(name), used))

	static __attribute__((noinline))
	int bar(int b) {
		return bpf_get_prandom_u32() > b;
	}

	SEC("xdp")
	int foo(struct xdp_md *ctx) {
		void *data = (void *)(long)ctx->data;
		void *data_end = (void *)(long)ctx->data_end;

		return bar(data_end - data);
	}

Here is the output from the existing version (using libbfd):

	# bpftool version
	bpftool v7.1.0
	using libbpf v1.1
	features: libbfd, libbpf_strict, skeletons

	# bpftool prog dump jited name foo
	int foo(struct xdp_md * ctx):
	bpf_prog_65e359e7b0251046_foo:
	; void *data = (void *)(long)ctx->data;
	   0:   nopl   0x0(%rax,%rax,1)
	   5:   xchg   %ax,%ax
	   7:   push   %rbp
	   8:   mov    %rsp,%rbp
	   b:   mov    0x0(%rdi),%rsi
	; void *data_end = (void *)(long)ctx->data_end;
	   f:   mov    0x8(%rdi),%rdi
	; return bar(data_end - data);
	  13:   sub    %esi,%edi
	; return bar(data_end - data);
	  15:   call   0x0000000000000038
	; return bar(data_end - data);
	  1a:   leave
	  1b:   ret

	int bar(int b):
	bpf_prog_9b001d67a67f01cc_bar:
	; int bar(int b) {
	   0:   nopl   0x0(%rax,%rax,1)
	   5:   xchg   %ax,%ax
	   7:   push   %rbp
	   8:   mov    %rsp,%rbp
	   b:   push   %rbx
	   c:   mov    %edi,%ebx
	; return bpf_get_prandom_u32() > b;
	   e:   call   0xffffffffcab00454
	  13:   mov    %eax,%edi
	  15:   mov    $0x1,%eax
	; return bpf_get_prandom_u32() > b;
	  1a:   cmp    %ebx,%edi
	  1c:   ja     0x0000000000000020
	  1e:   xor    %eax,%eax
	; return bpf_get_prandom_u32() > b;
	  20:   pop    %rbx
	  21:   leave
	  22:   ret

Did you expect "bar" to appear on insn '15:'? I don't think we get this
from bpftool at the moment? Or did I misunderstand your question?

The output from LLVM's disassembler comes below:

	# ./bpftool version
	bpftool v7.1.0
	using libbpf v1.1
	features: llvm, libbpf_strict, skeletons

	# ./bpftool prog dump jited name foo
	int foo(struct xdp_md * ctx):
	bpf_prog_65e359e7b0251046_foo:
	; void *data = (void *)(long)ctx->data;
	   0:   nopl    (%rax,%rax)
	   5:   nop
	   7:   pushq   %rbp
	   8:   movq    %rsp, %rbp
	   b:   movq    (%rdi), %rsi
	; void *data_end = (void *)(long)ctx->data_end;
	   f:   movq    8(%rdi), %rdi
	; return bar(data_end - data);
	  13:   subl    %esi, %edi
	; return bar(data_end - data);
	  15:   callq   0x38
	; return bar(data_end - data);
	  1a:   leave
	  1b:   retq

	int bar(int b):
	bpf_prog_9b001d67a67f01cc_bar:
	; int bar(int b) {
	   0:   nopl    (%rax,%rax)
	   5:   nop
	   7:   pushq   %rbp
	   8:   movq    %rsp, %rbp
	   b:   pushq   %rbx
	   c:   movl    %edi, %ebx
	; return bpf_get_prandom_u32() > b;
	   e:   callq   0xffffffffcab00454
	  13:   movl    %eax, %edi
	  15:   movl    $1, %eax
	; return bpf_get_prandom_u32() > b;
	  1a:   cmpl    %ebx, %edi
	  1c:   ja      0x20
	  1e:   xorl    %eax, %eax
	; return bpf_get_prandom_u32() > b;
	  20:   popq    %rbx
	  21:   leave
	  22:   retq

LLVM, but _without_ the LLVMDisassembler_ReferenceType_InOut_None:

	int foo(struct xdp_md * ctx):
	bpf_prog_65e359e7b0251046_foo:
	; void *data = (void *)(long)ctx->data;
	   0:   nopl    (%rax,%rax)
	   5:   nop
	   7:   pushq   %rbp
	   8:   movq    %rsp, %rbp
	   b:   movq    (%rdi), %rsi
	; void *data_end = (void *)(long)ctx->data_end;
	   f:   movq    8(%rdi), %rdi
	; return bar(data_end - data);
	  13:   subl    %esi, %edi
	; return bar(data_end - data);
	  15:   callq   30
	; return bar(data_end - data);
	  1a:   leave
	  1b:   retq

	int bar(int b):
	bpf_prog_9b001d67a67f01cc_bar:
	; int bar(int b) {
	   0:   nopl    (%rax,%rax)
	   5:   nop
	   7:   pushq   %rbp
	   8:   movq    %rsp, %rbp
	   b:   pushq   %rbx
	   c:   movl    %edi, %ebx
	; return bpf_get_prandom_u32() > b;
	   e:   callq   -894434239
	  13:   movl    %eax, %edi
	  15:   movl    $1, %eax
	; return bpf_get_prandom_u32() > b;
	  1a:   cmpl    %ebx, %edi
	  1c:   ja      2
	  1e:   xorl    %eax, %eax
	; return bpf_get_prandom_u32() > b;
	  20:   popq    %rbx
	  21:   leave
	  22:   retq


  reply	other threads:[~2022-10-24 11:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 12:36 [PATCH bpf-next v3 0/8] bpftool: Add LLVM as default library for disassembling JIT-ed programs Quentin Monnet
2022-10-20 12:36 ` [PATCH bpf-next v3 1/8] bpftool: Define _GNU_SOURCE only once Quentin Monnet
2022-10-20 12:36 ` [PATCH bpf-next v3 2/8] bpftool: Remove asserts from JIT disassembler Quentin Monnet
2022-10-20 12:36 ` [PATCH bpf-next v3 3/8] bpftool: Split FEATURE_TESTS/FEATURE_DISPLAY definitions in Makefile Quentin Monnet
2022-10-20 12:37 ` [PATCH bpf-next v3 4/8] bpftool: Group libbfd defs in Makefile, only pass them if we use libbfd Quentin Monnet
2022-10-20 12:37 ` [PATCH bpf-next v3 5/8] bpftool: Refactor disassembler for JIT-ed programs Quentin Monnet
2022-10-20 12:37 ` [PATCH bpf-next v3 6/8] bpftool: Add LLVM as default library for disassembling " Quentin Monnet
2022-10-20 17:49   ` Alexei Starovoitov
2022-10-24 11:05     ` Quentin Monnet [this message]
2022-10-24 18:40       ` Alexei Starovoitov
2022-10-25  2:23         ` Alexei Starovoitov
2022-10-20 12:37 ` [PATCH bpf-next v3 7/8] bpftool: Support setting alternative arch for JIT disasm with LLVM Quentin Monnet
2022-10-20 12:37 ` [PATCH bpf-next v3 8/8] bpftool: Add llvm feature to "bpftool version" Quentin Monnet
2022-10-21 22:38   ` Andrii Nakryiko
2022-10-24 11:09     ` Quentin Monnet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1dc2c77a-2dea-25a4-fa64-b65460c7f1cb@isovalent.com \
    --to=quentin@isovalent.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=niklas.soderlund@corigine.com \
    --cc=sdf@google.com \
    --cc=simon.horman@corigine.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox