Re: [suricata PATCH 1/3] suricata/ebpf: take clang -target bpf include issue of stdint.h into account
From: Jesper Dangaard Brouer <hidden>
Date: 2018-02-08 08:42:56
On Thu, 08 Feb 2018 00:52:09 +0100 Eric Leblond [off-list ref] wrote:
Hi, On Wed, 2018-02-07 at 23:21 +0100, Jesper Dangaard Brouer wrote:quoted
From: Jesper Dangaard Brouer <redacted> 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...quoted
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.
quoted hunk ↗ jump to hunk
"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