| Message ID | 20200312130330.32239-1-tklauser@distanz.ch |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [bpf-next,v2] bpftool: use linux/types.h from source tree for profiler build | expand |
2020-03-12 14:03 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch> > When compiling bpftool on a system where the /usr/include/asm symlink > doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), > the build fails with: > > CLANG skeleton/profiler.bpf.o > In file included from skeleton/profiler.bpf.c:4: > In file included from /usr/include/linux/bpf.h:11: > /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found > #include <asm/types.h> > ^~~~~~~~~~~~~ > 1 error generated. > make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 > > This indicates that the build is using linux/types.h from system headers > instead of source tree headers. > > To fix this, adjust the clang search path to include the necessary > headers from tools/testing/selftests/bpf/include/uapi and > tools/include/uapi. Also use __bitwise__ instead of __bitwise in > skeleton/profiler.h to avoid clashing with the definition in > tools/testing/selftests/bpf/include/uapi/linux/types.h. > > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Song Liu <songliubraving@fb.com> > Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> > Cc: Quentin Monnet <quentin@isovalent.com> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Looks good, thanks! Reviewed-by: Quentin Monnet <quentin@isovalent.com>
On 3/12/20 3:15 PM, Quentin Monnet wrote: > 2020-03-12 14:03 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch> >> When compiling bpftool on a system where the /usr/include/asm symlink >> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), >> the build fails with: >> >> CLANG skeleton/profiler.bpf.o >> In file included from skeleton/profiler.bpf.c:4: >> In file included from /usr/include/linux/bpf.h:11: >> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found >> #include <asm/types.h> >> ^~~~~~~~~~~~~ >> 1 error generated. >> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 >> >> This indicates that the build is using linux/types.h from system headers >> instead of source tree headers. >> >> To fix this, adjust the clang search path to include the necessary >> headers from tools/testing/selftests/bpf/include/uapi and >> tools/include/uapi. Also use __bitwise__ instead of __bitwise in >> skeleton/profiler.h to avoid clashing with the definition in >> tools/testing/selftests/bpf/include/uapi/linux/types.h. >> >> Cc: Daniel Borkmann <daniel@iogearbox.net> >> Cc: Song Liu <songliubraving@fb.com> >> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> >> Cc: Quentin Monnet <quentin@isovalent.com> >> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> > > Looks good, thanks! > Reviewed-by: Quentin Monnet <quentin@isovalent.com> Applied, thanks (compiles fine over here as well now)!
On Thu, Mar 12, 2020 at 6:04 AM Tobias Klauser <tklauser@distanz.ch> wrote: > > When compiling bpftool on a system where the /usr/include/asm symlink > doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), > the build fails with: > > CLANG skeleton/profiler.bpf.o > In file included from skeleton/profiler.bpf.c:4: > In file included from /usr/include/linux/bpf.h:11: > /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found > #include <asm/types.h> > ^~~~~~~~~~~~~ > 1 error generated. > make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 > > This indicates that the build is using linux/types.h from system headers > instead of source tree headers. > > To fix this, adjust the clang search path to include the necessary > headers from tools/testing/selftests/bpf/include/uapi and > tools/include/uapi. Also use __bitwise__ instead of __bitwise in > skeleton/profiler.h to avoid clashing with the definition in > tools/testing/selftests/bpf/include/uapi/linux/types.h. > > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Song Liu <songliubraving@fb.com> > Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> > Cc: Quentin Monnet <quentin@isovalent.com> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch> > --- > tools/bpf/bpftool/Makefile | 5 ++++- > tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++--------- > 2 files changed, 12 insertions(+), 10 deletions(-) > > diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile > index 20a90d8450f8..f294f6c1e795 100644 > --- a/tools/bpf/bpftool/Makefile > +++ b/tools/bpf/bpftool/Makefile > @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF) > $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS) > > skeleton/profiler.bpf.o: skeleton/profiler.bpf.c > - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ > + $(QUIET_CLANG)$(CLANG) \ > + -I$(srctree)/tools/include/uapi/ \ > + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \ Seems like I'm spoiling all the fun today :) But why are we ok with bpftool build depending on selftests? This just makes it even harder to have a stand-alone bpftool build eventually (similar to libbpf's Github). > + -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ > > profiler.skel.h: $(OUTPUT)_bpftool skeleton/profiler.bpf.o > $(QUIET_GEN)$(OUTPUT)./_bpftool gen skeleton skeleton/profiler.bpf.o > $@ > diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h > index e03b53eae767..1f767e9510f7 100644 > --- a/tools/bpf/bpftool/skeleton/profiler.h > +++ b/tools/bpf/bpftool/skeleton/profiler.h > @@ -32,16 +32,15 @@ enum { > #else > #define __bitwise__ > #endif > -#define __bitwise __bitwise__ > > -typedef __u16 __bitwise __le16; > -typedef __u16 __bitwise __be16; > -typedef __u32 __bitwise __le32; > -typedef __u32 __bitwise __be32; > -typedef __u64 __bitwise __le64; > -typedef __u64 __bitwise __be64; > +typedef __u16 __bitwise__ __le16; > +typedef __u16 __bitwise__ __be16; > +typedef __u32 __bitwise__ __le32; > +typedef __u32 __bitwise__ __be32; > +typedef __u64 __bitwise__ __le64; > +typedef __u64 __bitwise__ __be64; > > -typedef __u16 __bitwise __sum16; > -typedef __u32 __bitwise __wsum; > +typedef __u16 __bitwise__ __sum16; > +typedef __u32 __bitwise__ __wsum; > > #endif /* __PROFILER_H */ > -- > 2.25.1 >
On 3/12/20 6:59 PM, Andrii Nakryiko wrote: > On Thu, Mar 12, 2020 at 6:04 AM Tobias Klauser <tklauser@distanz.ch> wrote: >> >> When compiling bpftool on a system where the /usr/include/asm symlink >> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), >> the build fails with: >> >> CLANG skeleton/profiler.bpf.o >> In file included from skeleton/profiler.bpf.c:4: >> In file included from /usr/include/linux/bpf.h:11: >> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found >> #include <asm/types.h> >> ^~~~~~~~~~~~~ >> 1 error generated. >> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 >> >> This indicates that the build is using linux/types.h from system headers >> instead of source tree headers. >> >> To fix this, adjust the clang search path to include the necessary >> headers from tools/testing/selftests/bpf/include/uapi and >> tools/include/uapi. Also use __bitwise__ instead of __bitwise in >> skeleton/profiler.h to avoid clashing with the definition in >> tools/testing/selftests/bpf/include/uapi/linux/types.h. >> >> Cc: Daniel Borkmann <daniel@iogearbox.net> >> Cc: Song Liu <songliubraving@fb.com> >> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> >> Cc: Quentin Monnet <quentin@isovalent.com> >> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> >> --- >> tools/bpf/bpftool/Makefile | 5 ++++- >> tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++--------- >> 2 files changed, 12 insertions(+), 10 deletions(-) >> >> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile >> index 20a90d8450f8..f294f6c1e795 100644 >> --- a/tools/bpf/bpftool/Makefile >> +++ b/tools/bpf/bpftool/Makefile >> @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF) >> $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS) >> >> skeleton/profiler.bpf.o: skeleton/profiler.bpf.c >> - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ >> + $(QUIET_CLANG)$(CLANG) \ >> + -I$(srctree)/tools/include/uapi/ \ >> + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \ > > Seems like I'm spoiling all the fun today :) But why are we ok with > bpftool build depending on selftests? This just makes it even harder > to have a stand-alone bpftool build eventually (similar to libbpf's > Github). I suspect the Github copy of bpftool would have its own include infra like in case of libbpf [0]? Agree in any case that it's not an optimal situation with this dependency; I suspect we might need the tools/testing/selftests/bpf/include/uapi/ under tools/include/uapi/ in a proper way. [0] https://github.com/libbpf/libbpf/tree/master/include
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 20a90d8450f8..f294f6c1e795 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF) $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS) skeleton/profiler.bpf.o: skeleton/profiler.bpf.c - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ + $(QUIET_CLANG)$(CLANG) \ + -I$(srctree)/tools/include/uapi/ \ + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \ + -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ profiler.skel.h: $(OUTPUT)_bpftool skeleton/profiler.bpf.o $(QUIET_GEN)$(OUTPUT)./_bpftool gen skeleton skeleton/profiler.bpf.o > $@ diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h index e03b53eae767..1f767e9510f7 100644 --- a/tools/bpf/bpftool/skeleton/profiler.h +++ b/tools/bpf/bpftool/skeleton/profiler.h @@ -32,16 +32,15 @@ enum { #else #define __bitwise__ #endif -#define __bitwise __bitwise__ -typedef __u16 __bitwise __le16; -typedef __u16 __bitwise __be16; -typedef __u32 __bitwise __le32; -typedef __u32 __bitwise __be32; -typedef __u64 __bitwise __le64; -typedef __u64 __bitwise __be64; +typedef __u16 __bitwise__ __le16; +typedef __u16 __bitwise__ __be16; +typedef __u32 __bitwise__ __le32; +typedef __u32 __bitwise__ __be32; +typedef __u64 __bitwise__ __le64; +typedef __u64 __bitwise__ __be64; -typedef __u16 __bitwise __sum16; -typedef __u32 __bitwise __wsum; +typedef __u16 __bitwise__ __sum16; +typedef __u32 __bitwise__ __wsum; #endif /* __PROFILER_H */
When compiling bpftool on a system where the /usr/include/asm symlink doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), the build fails with: CLANG skeleton/profiler.bpf.o In file included from skeleton/profiler.bpf.c:4: In file included from /usr/include/linux/bpf.h:11: /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found #include <asm/types.h> ^~~~~~~~~~~~~ 1 error generated. make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 This indicates that the build is using linux/types.h from system headers instead of source tree headers. To fix this, adjust the clang search path to include the necessary headers from tools/testing/selftests/bpf/include/uapi and tools/include/uapi. Also use __bitwise__ instead of __bitwise in skeleton/profiler.h to avoid clashing with the definition in tools/testing/selftests/bpf/include/uapi/linux/types.h. Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Song Liu <songliubraving@fb.com> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> --- tools/bpf/bpftool/Makefile | 5 ++++- tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++--------- 2 files changed, 12 insertions(+), 10 deletions(-)