From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [suricata PATCH 1/3] suricata/ebpf: take clang -target bpf include issue of stdint.h into account Date: Thu, 8 Feb 2018 09:42:52 +0100 Message-ID: <20180208094252.20267ecb@redhat.com> References: <151804202589.30000.6117096373101222054.stgit@firesoul> <151804207444.30000.12666757505388007849.stgit@firesoul> <1518047529.18958.16.camel@regit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: victor@inliniac.net, netdev@vger.kernel.org, yhs@fb.com, Daniel Borkmann , Alexei Starovoitov , brouer@redhat.com To: Eric Leblond Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53516 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750806AbeBHIm4 (ORCPT ); Thu, 8 Feb 2018 03:42:56 -0500 In-Reply-To: <1518047529.18958.16.camel@regit.org> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 08 Feb 2018 00:52:09 +0100 Eric Leblond wrote: > Hi, > > On Wed, 2018-02-07 at 23:21 +0100, Jesper Dangaard Brouer wrote: > > From: Jesper Dangaard Brouer > > > > This patch prepares code before enabling the clang -target bpf. > > > > The clang compiler does not like #include 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 > ^~~~~~~~~~~~~ > 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