All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: Latest libbpf fails to load programs compiled with old LLVM
Date: Thu, 3 Dec 2020 17:42:28 -0800	[thread overview]
Message-ID: <10679e62-50a2-4c01-31d2-cb79c01e4cbf@fb.com> (raw)
In-Reply-To: <87lfeebwpu.fsf@toke.dk>



On 12/3/20 9:55 AM, Toke Høiland-Jørgensen wrote:
> Hi Andrii
> 
> I noticed that recent libbpf versions fail to load BPF files compiled
> with old versions of LLVM. E.g., if I compile xdp-tools with LLVM 7 I
> get:
> 
> $ sudo ./xdp-loader load testns ../lib/testing/xdp_drop.o -vv
> Loading 1 files on interface 'testns'.
> libbpf: loading ../lib/testing/xdp_drop.o
> libbpf: elf: section(3) prog, size 16, link 0, flags 6, type=1
> libbpf: sec 'prog': failed to find program symbol at offset 0
> Couldn't open file '../lib/testing/xdp_drop.o': BPF object format invalid
> 
> The 'failed to find program symbol' error seems to have been introduced
> with commit c112239272c6 ("libbpf: Parse multi-function sections into
> multiple BPF programs").
> 
> Looking at the object file in question, indeed it seems to not have any
> function symbols defined:
> 
> $  llvm-objdump --syms ../lib/testing/xdp_drop.o
> 
> ../lib/testing/xdp_drop.o:	file format elf64-bpf
> 
> SYMBOL TABLE:
> 0000000000000000 l       .debug_str	0000000000000000
> 0000000000000037 l       .debug_str	0000000000000000
> 0000000000000042 l       .debug_str	0000000000000000
> 0000000000000068 l       .debug_str	0000000000000000
> 0000000000000071 l       .debug_str	0000000000000000
> 0000000000000076 l       .debug_str	0000000000000000
> 000000000000008a l       .debug_str	0000000000000000
> 0000000000000097 l       .debug_str	0000000000000000
> 00000000000000a3 l       .debug_str	0000000000000000
> 00000000000000ac l       .debug_str	0000000000000000
> 00000000000000b5 l       .debug_str	0000000000000000
> 00000000000000bc l       .debug_str	0000000000000000
> 00000000000000c9 l       .debug_str	0000000000000000
> 00000000000000d4 l       .debug_str	0000000000000000
> 00000000000000dd l       .debug_str	0000000000000000
> 00000000000000e1 l       .debug_str	0000000000000000
> 00000000000000e5 l       .debug_str	0000000000000000
> 00000000000000ea l       .debug_str	0000000000000000
> 00000000000000f0 l       .debug_str	0000000000000000
> 00000000000000f9 l       .debug_str	0000000000000000
> 0000000000000103 l       .debug_str	0000000000000000
> 0000000000000113 l       .debug_str	0000000000000000
> 0000000000000122 l       .debug_str	0000000000000000
> 0000000000000131 l       .debug_str	0000000000000000
> 0000000000000000 l    d  prog	0000000000000000 prog
> 0000000000000000 l    d  .debug_abbrev	0000000000000000 .debug_abbrev
> 0000000000000000 l    d  .debug_info	0000000000000000 .debug_info
> 0000000000000000 l    d  .debug_frame	0000000000000000 .debug_frame
> 0000000000000000 l    d  .debug_line	0000000000000000 .debug_line
> 0000000000000000 g       license	0000000000000000 _license
> 0000000000000000 g       prog	0000000000000000 xdp_drop
> 
> 
> I assume this is because old LLVM versions simply don't emit that symbol
> information?

Could you share xdp_drop.c or other test which I can compile and check
to understand the issue?

> 
> Anyhow, the patch series that introduced this restructures the program
> parsing some, so I wanted to get your input to make sure I don't break
> things when fixing this regression. So what's the best way to fix it?
> Just assume that the whole section is one program if no symbols are
> present, or is the some subtle reason why that would break any of the
> other logic for BPF-to-BPF calls?
> 
> -Toke
> 

  reply	other threads:[~2020-12-04  1:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 17:55 Latest libbpf fails to load programs compiled with old LLVM Toke Høiland-Jørgensen
2020-12-04  1:42 ` Yonghong Song [this message]
2020-12-04  9:34   ` Toke Høiland-Jørgensen
2020-12-04 17:54     ` Yonghong Song
2020-12-04 19:23       ` Andrii Nakryiko
2020-12-07 10:59         ` Toke Høiland-Jørgensen
2020-12-07 15:55           ` Alexei Starovoitov
2020-12-07 16:15             ` Toke Høiland-Jørgensen
2020-12-07 16:20               ` Alexei Starovoitov
2020-12-07 16:51                 ` Toke Høiland-Jørgensen
2020-12-07 17:16                   ` Alexei Starovoitov
2020-12-07 22:18                     ` Toke Høiland-Jørgensen
2020-12-08  1:20                       ` Alexei Starovoitov
2020-12-07 18:02                 ` David Ahern
2020-12-07 18:14                   ` Alexei Starovoitov
2020-12-07 18:59                     ` David Ahern
2020-12-08  2:47           ` Andrii Nakryiko
2020-12-08 13:41             ` Toke Høiland-Jørgensen
2020-12-08 18:39               ` Andrii Nakryiko
2020-12-08 22:38                 ` Toke Høiland-Jørgensen

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=10679e62-50a2-4c01-31d2-cb79c01e4cbf@fb.com \
    --to=yhs@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=toke@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.