Re: Latest libbpf fails to load programs compiled with old LLVM

["Toke Høiland-Jørgensen" <toke@redhat.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