On Thu, 08 Feb 2018 00:52:09 +0100 Eric Leblond <e...@regit.org> wrote:
> Hi,
>
> On Wed, 2018-02-07 at 23:21 +0100, Jesper Dangaard Brouer wrote:
> > From: Jesper Dangaard Brouer <netoptimi...@brouer.com>
> >
> > This patch prepares code before enabling the clang -target bpf.
> >
> > The clang compiler does not like #include <stdint.h> when
> > using '-target bpf' it will fail with:
> >
> > fatal error: 'gnu/stubs-32.h' file not found
> ...
> > This can be worked around by installing the 32-bit version of
> > glibc-devel.i686 on your distribution.
> >
> > But the BPF programs does not really need to include stdint.h,
> > if converting:
> > uint64_t -> __u64
> > uint32_t -> __u32
> > uint16_t -> __u16
> > uint8_t -> __u8
> >
> > This patch does this type syntax conversion.
>
> There is an issue for system like Debian because they don't have a
> asm/types.h in the include path if the architecture is not defined
> which is the case due to target bpf. This results in:
>
> clang-5.0 -Wall -Iinclude -O2 \
> -D__KERNEL__ -D__ASM_SYSREG_H \
> -target bpf -S -emit-llvm vlan_filter.c -o vlan_filter.ll
> In file included from vlan_filter.c:19:
> In file included from include/linux/bpf.h:11:
> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not
> found
> #include <asm/types.h>
> ^~~~~~~~~~~~~
> 1 error generated.
> Makefile:523: recipe for target 'vlan_filter.bpf' failed
>
> To go into details, the Debian package providing the 'asm/typs.h'
> include is the the headers or linux-libc-dev. But this package comes
> with a flavor and thus we have a prefix:
> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
Oh, the joy of distro choices.
> "Fun" part here is that if you build a debian package of the via make
> in Linux tree then the linux-libc-dev package is correct.
>
> So I propose the following patch that fixes the issue for me:
>
> diff --git a/ebpf/Makefile.am b/ebpf/Makefile.am
> index 89a3304e9..712b05343 100644
> --- a/ebpf/Makefile.am
> +++ b/ebpf/Makefile.am
> @@ -16,6 +16,7 @@ all: $(BPF_TARGETS)
> $(BPF_TARGETS): %.bpf: %.c
> # From C-code to LLVM-IR format suffix .ll (clang -S -emit-llvm)
> ${CLANG} -Wall $(BPF_CFLAGS) -O2 \
> + -I/usr/include/$(host_cpu)-$(host_os)/ \
Cool solution. These variables originate from configure/automake.
Would it be more technical correct to use(?): $(build_cpu)-$(build_os)
I verified that the variables are the same (notice 'make -p' trick):
$ make -p | egrep '_os'
build_os = linux-gnu
host_os = linux-gnu
$ make -p | egrep '_cpu'
host_cpu = x86_64
build_cpu = x86_64
> -D__KERNEL__ -D__ASM_SYSREG_H \
> -target bpf -S -emit-llvm $< -o ${@:.bpf=.ll}
> # From LLVM-IR to BPF-bytecode in ELF-obj file
>
> Let me know if it is ok for you.
I'm fine with this fix.
I wonder if we should check other distros?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
