> On Wed, Jul 6, 2022 at 10:13 AM James Hilliard > <james.hilliard1@xxxxxxxxx> wrote: >> >> Note I'm testing with the following patches: >> https://lore.kernel.org/bpf/20220706111839.1247911-1-james.hilliard1@xxxxxxxxx/ >> https://lore.kernel.org/bpf/20220706140623.2917858-1-james.hilliard1@xxxxxxxxx/ >> >> It would appear there's some compatibility issues with bpftool gen and >> GCC, not sure what side though is wrong here: >> /home/buildroot/buildroot/output/per-package/systemd/host/sbin/bpftool >> gen object src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.o >> src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.unstripped.o >> libbpf: failed to find BTF info for global/extern symbol 'sd_restrictif_i' >> Error: failed to link >> 'src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.unstripped.o': >> Unknown error -2 (-2) >> >> Relevant difference seems to be this: >> GCC: >> [55] FUNC 'sd_restrictif_i' type_id=47 linkage=static >> Clang: >> [27] FUNC 'sd_restrictif_i' type_id=26 linkage=global For functions GCC generates a BTF_KIND_FUNC entry, which has no linkage information, or so we thought: I just looked at bpftool/btf.c and I found the linkage info for function types is expected to be encoded in the vlen field of BTF_KIND_FUNC entries (why not adding a btf_func instead???) which is surprising to say the least. We are changing GCC to encode the linkage info in vlen for these types. Thanks for reporting this. > GCC is wrong, clearly. This function is global ([0]) and libbpf > expects it to be marked as such in BTF. > > https://github.com/systemd/systemd/blob/main/src/core/bpf/restrict_ifaces/restrict-ifaces.bpf.c#L42-L50 > > >> GCC: >> >> [1] INT 'signed char' size=1 bits_offset=0 nr_bits=8 encoding=UNKN >> [2] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=CHAR >> [3] TYPEDEF '__u8' type_id=2 >> [4] CONST '(anon)' type_id=3 > > [...]
