All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yonghong Song <yhs@fb.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: Fri, 04 Dec 2020 10:34:43 +0100	[thread overview]
Message-ID: <87r1o59aoc.fsf@toke.dk> (raw)
In-Reply-To: <10679e62-50a2-4c01-31d2-cb79c01e4cbf@fb.com>

Yonghong Song <yhs@fb.com> writes:

> 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?

It's just an empty program returning XDP_DROP:

https://github.com/xdp-project/xdp-tools/blob/master/lib/testing/xdp_drop.c

I basically just did this on Debian buster:

$ sudo apt install gcc-multilib build-essential libpcap-dev libelf-dev git llc lld clang gcc-multilib pkt-config m4
$ git clone --recurse-submodules https://github.com/xdp-project/xdp-tools
$ cd xdp-tools
$ LLC=llc-7 ./configure
$ make -k
$ cd xdp-loader
$ sudo ip link add dev testns type veth
$ sudo ./xdp-loader load testns ../lib/testing/xdp_drop.o -vv

(xdpdump will fail to build with llvm7, but the rest should work)

-Toke


  reply	other threads:[~2020-12-04  9:36 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
2020-12-04  9:34   ` Toke Høiland-Jørgensen [this message]
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=87r1o59aoc.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --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 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.