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

[Yonghong Song <yhs@fb.com>]

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
>