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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux