lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <9afe8b73-806c-1511-dd26-f09e67b85107@fb.com> Date: Thu, 11 May 2017 15:58:33 -0700 From: Alexei Starovoitov <ast@...com> To: David Miller <davem@...emloft.net> CC: <daniel@...earbox.net>, <netdev@...r.kernel.org> Subject: Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__ On 5/11/17 12:02 PM, David Miller wrote: > From: Alexei Starovoitov <ast@...com> > Date: Thu, 4 May 2017 16:34:08 -0700 > >> Hence I think the cleanest solution is to have bpf arch's types.h >> either installed with llvm/gcc or picked from selftests's dir. > > Something like this? yes :) Ack. > ==================== > [PATCH] bpf: Provide a linux/types.h override for bpf selftests. > > We do not want to use the architecture's type.h header when > building BPF programs which are always 64-bit. > > Signed-off-by: David S. Miller <davem@...emloft.net> > --- > tools/testing/selftests/bpf/Makefile | 3 ++- > tools/testing/selftests/bpf/include/uapi/linux/types.h | 6 ++++++ > 2 files changed, 8 insertions(+), 1 deletion(-) > create mode 100644 tools/testing/selftests/bpf/include/uapi/linux/types.h > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > index f92f27d..f389b02 100644 > --- a/tools/testing/selftests/bpf/Makefile > +++ b/tools/testing/selftests/bpf/Makefile > @@ -35,6 +35,7 @@ $(BPFOBJ): force > CLANG ?= clang > > %.o: %.c > - $(CLANG) -I. -I../../../include/uapi -I../../../../samples/bpf/ \ > + $(CLANG) -I. -I./include/uapi -I../../../include/uapi \ Can we than move gnu/stubs.h into include/uapi as well and remove the first -I. ? Or keep them separate, since this linux/types.h is bpf's arch types.h whereas gnu/stubs.h is a hack for glibc /usr/include/features.h ? I'm fine whichever way including keeping this patch as-is.
Powered by blists - more mailing lists