>> 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. Patch sent to GCC upstream: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598090.html >> 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 >> >> [...]
