From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [bpf-next V2 PATCH 5/5] tools/libbpf: handle issues with bpf ELF objects containing .eh_frames Date: Wed, 7 Feb 2018 15:58:11 +0100 Message-ID: <20180207155811.4e0e18e3@redhat.com> References: <151792880187.16520.14567856474057331630.stgit@firesoul> <151792886827.16520.13497757653052246816.stgit@firesoul> <20180206160057.jxf7qc64jq2gmrf2@ast-mbp.dhcp.thefacebook.com> <20180206180348.469344b2@redhat.com> <916e63e2-392f-2e22-327d-635deb3687c8@iogearbox.net> <20180207134036.0cfa8bda@redhat.com> <5e9c9b1c-e3ee-a237-9536-319cf118ff09@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexei Starovoitov , netdev@vger.kernel.org, Daniel Borkmann , wangnan0@huawei.com, jakub.kicinski@netronome.com, joe@ovn.org, acme@redhat.com, eric@regit.org, yhs@fb.com, Victor Julien , brouer@redhat.com To: Daniel Borkmann Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53816 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754138AbeBGO6S (ORCPT ); Wed, 7 Feb 2018 09:58:18 -0500 In-Reply-To: <5e9c9b1c-e3ee-a237-9536-319cf118ff09@iogearbox.net> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 7 Feb 2018 14:19:00 +0100 Daniel Borkmann wrote: > On 02/07/2018 01:40 PM, Jesper Dangaard Brouer wrote: > > On Tue, 6 Feb 2018 20:05:43 +0100 Daniel Borkmann wrote: > >> On 02/06/2018 06:03 PM, Jesper Dangaard Brouer wrote: > > [...] > >>> [...] I plan to follow up and do a more complete solution later. This > >>> is a workaround to get the Suricata use-case working and also that > >>> samples/bpf/ can be loaded. > >> > >> Aside from a needed fix in any case, is there a specifc reason why Suricata > >> cannot rely on 'clang -target bpf'? Is it asm inline headers in your case? > > > > Below is the error I get when using 'clang' with '-target bpf' > > > > $ dirs > > ~/git/suricata/src/ebpf > > > > $ clang -Wall -Iinclude -O2 -D__KERNEL__ -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf > > In file included from xdp_filter.c:19: > > In file included from /usr/bin/../lib64/clang/4.0.1/include/stdint.h:63: > > In file included from /usr/include/stdint.h:26: > > In file included from /usr/include/bits/libc-header-start.h:33: > > In file included from /usr/include/features.h:434: > > /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found > > # include > > ^~~~~~~~~~~~~~~~ > > > > I'll leave it up to Eric Leblond to figure out that he need to change > > in the eBPF programs to make it compile with '-target bpf'. Maybe you > > can offer him some guidance here? > > > > Direct link to code: > > https://github.com/OISF/suricata/blob/master/ebpf/xdp_filter.c > > Sure, you just need glibc-devel.i686, see: > > $ clang -Wall -Iinclude -O2 -D__KERNEL__ -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf > In file included from xdp_filter.c:19: > In file included from /home/darkstar/llvm/build/lib/clang/7.0.0/include/stdint.h:63: > In file included from /usr/include/stdint.h:25: > In file included from /usr/include/features.h:392: > /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found > # include > ^~~~~~~~~~~~~~~~ > 1 error generated. > # yum install glibc-devel.i686 > [...] > $ clang -Wall -Iinclude -O2 -D__KERNEL__ -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf > $ Could you please explain why if makes a difference to install glibc-devel.i686 ? How will people compiling suricata figure out the new dependency, that on their 64-bit (x86_64) distro's they also need to install the 32-bit (i686) variant of glibc-devel ? > Alternatively, you could do something like done in selftests to provide a > dummy, see commit 1c2dd16add7e ("selftests/bpf: get rid of -D__x86_64__"). That is a funny way to workaround the problem (having an empty file in include path), but it might be a better solution to avoid frustrations for people compiling suricata. An alternative solution is to NOT: #include #include And then change: uint64_t -> __u64 uint32_t -> __u32 uint16_t -> __u16 uint8_t -> __u8 -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer