On Fri, Apr 21, 2017 at 03:02:26PM -0400, David Miller wrote: > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Date: Fri, 21 Apr 2017 11:49:37 -0700 > > > On Fri, Apr 21, 2017 at 12:46:40PM -0400, David Miller wrote: > >> From: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > >> Date: Mon, 17 Apr 2017 20:44:35 +0200 > >> > >> > There is samples/bpf/sockex3_kern.c, which exercises it. To > >> > run it, it would be (clang/llvm needed due to BPF backend not > >> > available in gcc): > >> > > >> > # cd samples/bpf > >> > # make > >> > # ./sockex3 > >> > IP src.port -> dst.port bytes packets > >> > 127.0.0.1.12865 -> 127.0.0.1.49711 148 2 > >> > 127.0.0.1.49711 -> 127.0.0.1.12865 108 2 > >> > [...] > >> > > >> > Inside parse_eth_proto(), it will do tail calls based on the > >> > eth protocol. Over time, we'll move such C based tests over to > >> > tools/testing/selftests/bpf/. > >> > >> Ok, after a lot of work setting up an LLVM/CLANG environment and other > >> things, > > > > was it painful because of sparc environment? > > Yes, primarily this was the reason. > > It wasn't just a matter of building llvm/clang, I had to install a > whole new version of gcc because of llvm/clang build requirements. > > Also, it isn't clear what is supposed to happen when the system > include files are older than the one in the kernel tree. I thought it > should just work and the selftests and samples would pick up the ones > in the tree properly. interesting... It should pick up local headers without touching /usr/include. In the past I used to do 'make headers_install' before doing a build in samples/bpf or selftests, but then suddenly it started working without that step, so I figured something got fixed in the build system. May be it's arch specific somehow. > > redhat folks have been back and forth on adding bpf support to gcc. > > The backend itself was fully functional before it was abandoned. > > Last time we discussed it the lack of integrated asm in gcc was the main blocker. > > Can we bend gcc rules and let bpf backend emit custom binary and/or elf? > > I don't see why you can't just do a proper GNU as/ld port. > > Frankly I would love to write foo.s BFD assembler files just like for > any other target and them feed them to binutils. > > And then once you have BFD support for BPF ELF you get lots of tooling > and you can start going for gdb support. of course I agree :) That would be ideal. Just so far no one hacked BFD. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
