On Fri, Apr 20, 2018 at 11:06:03AM -0700, Yonghong Song wrote: > On 4/20/18 1:19 AM, Peter Zijlstra wrote:
> > Hurm, so adding __BPF__ for BPF compiles isn't an option? It seems to me > > having a CPP flag to identify BPF compile context might be useful in > > general. > > With "clang -target bpf", we already have __BPF__ defined. > For tracing, esp. ptrace.h is included, "clang -target <native_arch>" where > "-target <native_arch>" can be omitted, is typically used. > The reason is the native architecture header files typically > include a lot of various asm related stuff where "-target bpf" cannot > really handle. We relay on native clang to flush out all these > asm constructs and only bpf program needed stuff survives > reach to backend compiler. So because 'clang -target bpf' is 'broken', you do a work-around using 'clang -target <native_arch>'. But because that doesn't set __BPF__ you want to add NO_BPF_WORKAROUND to the kernel instead of adding __BPF__ to your build rules to better mimick -target bpf, which you should be using. How is that sane? Why not use 'clang -target <native_arch> -D__BPF__'
