On 5/3/17 9:06 AM, David Miller wrote:
From: David Miller <da...@davemloft.net>
Date: Wed, 03 May 2017 09:52:51 -0400 (EDT)
From: Alexei Starovoitov <a...@fb.com>
Date: Tue, 2 May 2017 21:14:43 -0700
-D__x86_64__ workaround was used to make /usr/include/features.h
to follow expected path through the system include headers.
This is not portable.
Instead define dummy stubs.h which is used by 'clang -target bpf'
Fixes: 6882804c916b ("selftests/bpf: add a test for overlapping packet range
checks")
Signed-off-by: Alexei Starovoitov <a...@kernel.org>
Applied, thanks for getting rid of this wart.
Actually, we're now back to the orignal problem I had on sparc.
The issue is that you cannot resolve the core kernel __u?? types
unless __sparc__ is properly defined.
In file included from
/home/davem/src/GIT/net/tools/testing/selftests/bpf/test_pkt_access.c:8:
In file included from ../../../include/uapi/linux/bpf.h:10:
/usr/include/linux/types.h:27:9: error: unknown type name '__u16'
typedef __u16 __bitwise __le16;
^
We really have to do the change I mentioned the first time I brought
up this issue, which is to get this via a variable set in the
per-arch top-level Makefile
I'd really like to avoid depending on kernel configuration.
This bit:
GENDIR := ../../../../include/generated
GENHDR := $(GENDIR)/autoconf.h
is already ugly, since it doesn't work in setups that build
out-of-source like ours.
As far as I can see
test_pkt_access.c:8 ->
tools/include/uapi/linux/bpf.h:10 ->
tools/include/linux/types.h:9 ->
/usr/include/asm/types.h -> asm-generic/int-ll64.h
as far as I can see that should be the same on most archs.
Why doesn't it work for sparc?
We can also copy paste include/uapi/asm-generic/int-ll64.h to
bpf/asm/types.h or something.
Since here we're compiling for bpf architecture adding
__x86_64__ or __sparc__ or __whatever_native_arch_here__ is incorrect.
It really should be bpf's arch types.h
Inside of it we can use '#ifdef __BPF__' to be more accurate which
is builtin macro for clang.
