| Message ID | 20190916105433.11404-1-ivan.khoronzhuk@linaro.org |
|---|---|
| Headers | show |
| Series | samples: bpf: improve/fix cross-compilation | expand |
On Mon, Sep 16, 2019 at 4:01 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > For cross compiling the target triple can be inherited from > cross-compile prefix as it's done in CLANG_FLAGS from kernel makefile. > So copy-paste this decision from kernel Makefile. > > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > --- Acked-by: Andrii Nakryiko <andriin@fb.com> > samples/bpf/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index 43dee90dffa4..b59e77e2250e 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -195,7 +195,7 @@ BTF_PAHOLE ?= pahole > # Detect that we're cross compiling and use the cross compiler > ifdef CROSS_COMPILE > HOSTCC = $(CROSS_COMPILE)gcc > -CLANG_ARCH_ARGS = -target $(ARCH) > +CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%)) > endif > > # Don't evaluate probes and warnings if we need to run make recursively > -- > 2.17.1 >
On Mon, Sep 16, 2019 at 4:01 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > It can overlap with CFLAGS used for libraries built with gcc if > not now then in next patches. Correct it here for simplicity. > > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > --- With GCC BPF front-end recently added, we should probably generalize this to something like BPF_EXTRA_CFLAGS or something like that, eventually. But for now: Acked-by: Andrii Nakryiko <andriin@fb.com> > samples/bpf/Makefile | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index b59e77e2250e..8ecc5d0c2d5b 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -218,10 +218,10 @@ BTF_LLVM_PROBE := $(shell echo "int main() { return 0; }" | \ > /bin/rm -f ./llvm_btf_verify.o) > > ifneq ($(BTF_LLVM_PROBE),) > - EXTRA_CFLAGS += -g > + CLANG_EXTRA_CFLAGS += -g > else > ifneq ($(and $(BTF_LLC_PROBE),$(BTF_PAHOLE_PROBE),$(BTF_OBJCOPY_PROBE)),) > - EXTRA_CFLAGS += -g > + CLANG_EXTRA_CFLAGS += -g > LLC_FLAGS += -mattr=dwarfris > DWARF2BTF = y > endif > @@ -280,8 +280,8 @@ $(obj)/hbm_edt_kern.o: $(src)/hbm.h $(src)/hbm_kern.h > # useless for BPF samples. > $(obj)/%.o: $(src)/%.c > @echo " CLANG-bpf " $@ > - $(Q)$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \ > - -I$(srctree)/tools/testing/selftests/bpf/ \ > + $(Q)$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(CLANG_EXTRA_CFLAGS) \ > + -I$(obj) -I$(srctree)/tools/testing/selftests/bpf/ \ > -D__KERNEL__ -D__BPF_TRACING__ -Wno-unused-value -Wno-pointer-sign \ > -D__TARGET_ARCH_$(SRCARCH) -Wno-compare-distinct-pointer-types \ > -Wno-gnu-variable-sized-type-not-at-end \ > -- > 2.17.1 >
Hello! On 16.09.2019 13:54, Ivan Khoronzhuk wrote: > While compile natively, the hosts cflags and ldflags are equal to ones Compiling. Host's. > used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should > have own, used for target arch. While verification, for arm, arm64 and > x86_64 the following flags were used alsways: > > -Wall > -O2 > -fomit-frame-pointer > -Wmissing-prototypes > -Wstrict-prototypes > > So, add them as they were verified and used before adding > Makefile.target, but anyway limit it only for cross compile options as > for host can be some configurations when another options can be used, > So, for host arch samples left all as is, it allows to avoid potential > option mistmatches for existent environments. Mismatches. > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> [...] MBR, Sergei
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > While compile natively, the hosts cflags and ldflags are equal to ones > used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should > have own, used for target arch. While verification, for arm, arm64 and > x86_64 the following flags were used alsways: > > -Wall > -O2 > -fomit-frame-pointer > -Wmissing-prototypes > -Wstrict-prototypes > > So, add them as they were verified and used before adding > Makefile.target, but anyway limit it only for cross compile options as > for host can be some configurations when another options can be used, > So, for host arch samples left all as is, it allows to avoid potential > option mistmatches for existent environments. > > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > --- > samples/bpf/Makefile | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index 1579cc16a1c2..b5c87a8b8b51 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR) > TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR) > endif > > +ifdef CROSS_COMPILE > +TPROGS_CFLAGS += -Wall > +TPROGS_CFLAGS += -O2 Specifying one arg per line seems like overkill, put them in one line? > +TPROGS_CFLAGS += -fomit-frame-pointer Why this one? > +TPROGS_CFLAGS += -Wmissing-prototypes > +TPROGS_CFLAGS += -Wstrict-prototypes Are these in some way special that we want them in cross-compile mode only? All of those flags seem useful regardless of cross-compilation or not, shouldn't they be common? I'm a bit lost about the intent here... > +else > TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) > TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) > +endif > + > TPROGS_CFLAGS += -I$(objtree)/usr/include > TPROGS_CFLAGS += -I$(srctree)/tools/lib/bpf/ > TPROGS_CFLAGS += -I$(srctree)/tools/testing/selftests/bpf/ > -- > 2.17.1 >
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > No need in hacking HOSTCC to be cross-compiler any more, so drop > this trick and use target CC for HDR_PROBE. > > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > --- Acked-by: Andrii Nakryiko <andriin@fb.com> [...]
On Mon, Sep 16, 2019 at 4:02 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > Thanks for these changes, they look good overall. It would be great if someone else could test and validate that cross-compilation works not just in your environment and generated binaries successfully run on target machines, though... [...] > > Ivan Khoronzhuk (14): > samples: bpf: makefile: fix HDR_PROBE "echo" > samples: bpf: makefile: fix cookie_uid_helper_example obj build > samples: bpf: makefile: use --target from cross-compile > samples: bpf: use own EXTRA_CFLAGS for clang commands > samples: bpf: makefile: use __LINUX_ARM_ARCH__ selector for arm > samples: bpf: makefile: drop unnecessarily inclusion for bpf_load > samples: bpf: add makefile.target for separate CC target build > samples: bpf: makefile: base target programs rules on Makefile.target > samples: bpf: makefile: use own flags but not host when cross compile > samples: bpf: makefile: use target CC environment for HDR_PROBE > libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf > targets > samples: bpf: makefile: provide C/CXX/LD flags to libbpf > samples: bpf: makefile: add sysroot support > samples: bpf: README: add preparation steps and sysroot info > Prefixes like "samples: bpf: makefile: " are very verbose without adding much value. We've been converging to essentially this set of prefixes: - "libbpf:" for libbpf changes - "bpftool:" for bpftool changes - "selftests/bpf:" for bpf selftests - "samples/bpf:" for bpf samples There is no need to prefix with "makefile: " either. Please update your patch subjects in the next version. Thanks! > samples/bpf/Makefile | 179 +++++++++++++++++++++--------------- > samples/bpf/Makefile.target | 75 +++++++++++++++ > samples/bpf/README.rst | 41 ++++++++- > tools/lib/bpf/Makefile | 11 ++- > 4 files changed, 225 insertions(+), 81 deletions(-) > create mode 100644 samples/bpf/Makefile.target > > -- > 2.17.1 >
On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote: >On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk ><ivan.khoronzhuk@linaro.org> wrote: >> >> While compile natively, the hosts cflags and ldflags are equal to ones >> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should >> have own, used for target arch. While verification, for arm, arm64 and >> x86_64 the following flags were used alsways: >> >> -Wall >> -O2 >> -fomit-frame-pointer >> -Wmissing-prototypes >> -Wstrict-prototypes >> >> So, add them as they were verified and used before adding >> Makefile.target, but anyway limit it only for cross compile options as >> for host can be some configurations when another options can be used, >> So, for host arch samples left all as is, it allows to avoid potential >> option mistmatches for existent environments. >> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> >> --- >> samples/bpf/Makefile | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile >> index 1579cc16a1c2..b5c87a8b8b51 100644 >> --- a/samples/bpf/Makefile >> +++ b/samples/bpf/Makefile >> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR) >> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR) >> endif >> >> +ifdef CROSS_COMPILE >> +TPROGS_CFLAGS += -Wall >> +TPROGS_CFLAGS += -O2 > >Specifying one arg per line seems like overkill, put them in one line? Will combine. > >> +TPROGS_CFLAGS += -fomit-frame-pointer > >Why this one? I've explained in commit msg. The logic is to have as much as close options to have smiliar binaries. As those options are used before for hosts and kinda cross builds - better follow same way. > >> +TPROGS_CFLAGS += -Wmissing-prototypes >> +TPROGS_CFLAGS += -Wstrict-prototypes > >Are these in some way special that we want them in cross-compile mode only? > >All of those flags seem useful regardless of cross-compilation or not, >shouldn't they be common? I'm a bit lost about the intent here... They are common but split is needed to expose it at least. Also host for different arches can have some own opts already used that shouldn't be present for cross, better not mix it for safety. > >> +else >> TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) >> TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) >> +endif >> + >> TPROGS_CFLAGS += -I$(objtree)/usr/include >> TPROGS_CFLAGS += -I$(srctree)/tools/lib/bpf/ >> TPROGS_CFLAGS += -I$(srctree)/tools/testing/selftests/bpf/ >> -- >> 2.17.1 >> -- Regards, Ivan Khoronzhuk
On Wed, Sep 18, 2019 at 3:35 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote: > >On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk > ><ivan.khoronzhuk@linaro.org> wrote: > >> > >> While compile natively, the hosts cflags and ldflags are equal to ones > >> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should > >> have own, used for target arch. While verification, for arm, arm64 and > >> x86_64 the following flags were used alsways: > >> > >> -Wall > >> -O2 > >> -fomit-frame-pointer > >> -Wmissing-prototypes > >> -Wstrict-prototypes > >> > >> So, add them as they were verified and used before adding > >> Makefile.target, but anyway limit it only for cross compile options as > >> for host can be some configurations when another options can be used, > >> So, for host arch samples left all as is, it allows to avoid potential > >> option mistmatches for existent environments. > >> > >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > >> --- > >> samples/bpf/Makefile | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > >> index 1579cc16a1c2..b5c87a8b8b51 100644 > >> --- a/samples/bpf/Makefile > >> +++ b/samples/bpf/Makefile > >> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR) > >> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR) > >> endif > >> > >> +ifdef CROSS_COMPILE > >> +TPROGS_CFLAGS += -Wall > >> +TPROGS_CFLAGS += -O2 > > > >Specifying one arg per line seems like overkill, put them in one line? > Will combine. > > > > >> +TPROGS_CFLAGS += -fomit-frame-pointer > > > >Why this one? > I've explained in commit msg. The logic is to have as much as close options > to have smiliar binaries. As those options are used before for hosts and kinda > cross builds - better follow same way. I'm just asking why omit frame pointers and make it harder to do stuff like profiling? What performance benefits are we seeking for in BPF samples? > > > > >> +TPROGS_CFLAGS += -Wmissing-prototypes > >> +TPROGS_CFLAGS += -Wstrict-prototypes > > > >Are these in some way special that we want them in cross-compile mode only? > > > >All of those flags seem useful regardless of cross-compilation or not, > >shouldn't they be common? I'm a bit lost about the intent here... > They are common but split is needed to expose it at least. Also host for > different arches can have some own opts already used that shouldn't be present > for cross, better not mix it for safety. We want -Wmissing-prototypes and -Wstrict-prototypes for cross-compile and non-cross-compile cases, right? So let's specify them as common set of options, instead of relying on KBUILD_HOSTCFLAGS or HOST_EXTRACFLAGS to have them. Otherwise we'll be getting extra warnings for just cross-compile case, which is not good. If you are worrying about having duplicate -W flags, seems like it's handled by GCC already, so shouldn't be a problem. > > > > >> +else > >> TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) > >> TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) > >> +endif > >> + > >> TPROGS_CFLAGS += -I$(objtree)/usr/include > >> TPROGS_CFLAGS += -I$(srctree)/tools/lib/bpf/ > >> TPROGS_CFLAGS += -I$(srctree)/tools/testing/selftests/bpf/ > >> -- > >> 2.17.1 > >> > > -- > Regards, > Ivan Khoronzhuk
On Wed, Sep 18, 2019 at 02:29:53PM -0700, Andrii Nakryiko wrote: >On Wed, Sep 18, 2019 at 3:35 AM Ivan Khoronzhuk ><ivan.khoronzhuk@linaro.org> wrote: >> >> On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote: >> >On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk >> ><ivan.khoronzhuk@linaro.org> wrote: >> >> >> >> While compile natively, the hosts cflags and ldflags are equal to ones >> >> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should >> >> have own, used for target arch. While verification, for arm, arm64 and >> >> x86_64 the following flags were used alsways: >> >> >> >> -Wall >> >> -O2 >> >> -fomit-frame-pointer >> >> -Wmissing-prototypes >> >> -Wstrict-prototypes >> >> >> >> So, add them as they were verified and used before adding >> >> Makefile.target, but anyway limit it only for cross compile options as >> >> for host can be some configurations when another options can be used, >> >> So, for host arch samples left all as is, it allows to avoid potential >> >> option mistmatches for existent environments. >> >> >> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> >> >> --- >> >> samples/bpf/Makefile | 9 +++++++++ >> >> 1 file changed, 9 insertions(+) >> >> >> >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile >> >> index 1579cc16a1c2..b5c87a8b8b51 100644 >> >> --- a/samples/bpf/Makefile >> >> +++ b/samples/bpf/Makefile >> >> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR) >> >> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR) >> >> endif >> >> >> >> +ifdef CROSS_COMPILE >> >> +TPROGS_CFLAGS += -Wall >> >> +TPROGS_CFLAGS += -O2 >> > >> >Specifying one arg per line seems like overkill, put them in one line? >> Will combine. >> >> > >> >> +TPROGS_CFLAGS += -fomit-frame-pointer >> > >> >Why this one? >> I've explained in commit msg. The logic is to have as much as close options >> to have smiliar binaries. As those options are used before for hosts and kinda >> cross builds - better follow same way. > >I'm just asking why omit frame pointers and make it harder to do stuff >like profiling? What performance benefits are we seeking for in BPF >samples? > >> >> > >> >> +TPROGS_CFLAGS += -Wmissing-prototypes >> >> +TPROGS_CFLAGS += -Wstrict-prototypes >> > >> >Are these in some way special that we want them in cross-compile mode only? >> > >> >All of those flags seem useful regardless of cross-compilation or not, >> >shouldn't they be common? I'm a bit lost about the intent here... >> They are common but split is needed to expose it at least. Also host for >> different arches can have some own opts already used that shouldn't be present >> for cross, better not mix it for safety. > >We want -Wmissing-prototypes and -Wstrict-prototypes for cross-compile >and non-cross-compile cases, right? So let's specify them as common >set of options, instead of relying on KBUILD_HOSTCFLAGS or >HOST_EXTRACFLAGS to have them. Otherwise we'll be getting extra >warnings for just cross-compile case, which is not good. If you are >worrying about having duplicate -W flags, seems like it's handled by >GCC already, so shouldn't be a problem. Ok, lets drop omit-frame-pointer. But then, lets do more radical step and drop KBUILD_HOSTCFLAGS & HOST_EXTRACFLAG in this patch: -ifdef CROSS_COMPILE +TPROGS_CFLAGS += -Wall -O2 +TPROGS_CFLAGS += -Wmissing-prototypes +TPROGS_CFLAGS += -Wstrict-prototypes -else -TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) -TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) -endif At least it allows to use same options always for both, native and cross. I verified on native x86_64, arm64 and arm and cross for arm and arm64, but should work for others, at least it can be tuned explicitly and no need to depend on KBUILD and use "cross" fork here. -- Regards, Ivan Khoronzhuk
On Thu, Sep 19, 2019 at 7:18 AM Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote: > > On Wed, Sep 18, 2019 at 02:29:53PM -0700, Andrii Nakryiko wrote: > >On Wed, Sep 18, 2019 at 3:35 AM Ivan Khoronzhuk > ><ivan.khoronzhuk@linaro.org> wrote: > >> > >> On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote: > >> >On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk > >> ><ivan.khoronzhuk@linaro.org> wrote: > >> >> > >> >> While compile natively, the hosts cflags and ldflags are equal to ones > >> >> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should > >> >> have own, used for target arch. While verification, for arm, arm64 and > >> >> x86_64 the following flags were used alsways: > >> >> > >> >> -Wall > >> >> -O2 > >> >> -fomit-frame-pointer > >> >> -Wmissing-prototypes > >> >> -Wstrict-prototypes > >> >> > >> >> So, add them as they were verified and used before adding > >> >> Makefile.target, but anyway limit it only for cross compile options as > >> >> for host can be some configurations when another options can be used, > >> >> So, for host arch samples left all as is, it allows to avoid potential > >> >> option mistmatches for existent environments. > >> >> > >> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> > >> >> --- > >> >> samples/bpf/Makefile | 9 +++++++++ > >> >> 1 file changed, 9 insertions(+) > >> >> > >> >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > >> >> index 1579cc16a1c2..b5c87a8b8b51 100644 > >> >> --- a/samples/bpf/Makefile > >> >> +++ b/samples/bpf/Makefile > >> >> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR) > >> >> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR) > >> >> endif > >> >> > >> >> +ifdef CROSS_COMPILE > >> >> +TPROGS_CFLAGS += -Wall > >> >> +TPROGS_CFLAGS += -O2 > >> > > >> >Specifying one arg per line seems like overkill, put them in one line? > >> Will combine. > >> > >> > > >> >> +TPROGS_CFLAGS += -fomit-frame-pointer > >> > > >> >Why this one? > >> I've explained in commit msg. The logic is to have as much as close options > >> to have smiliar binaries. As those options are used before for hosts and kinda > >> cross builds - better follow same way. > > > >I'm just asking why omit frame pointers and make it harder to do stuff > >like profiling? What performance benefits are we seeking for in BPF > >samples? > > > >> > >> > > >> >> +TPROGS_CFLAGS += -Wmissing-prototypes > >> >> +TPROGS_CFLAGS += -Wstrict-prototypes > >> > > >> >Are these in some way special that we want them in cross-compile mode only? > >> > > >> >All of those flags seem useful regardless of cross-compilation or not, > >> >shouldn't they be common? I'm a bit lost about the intent here... > >> They are common but split is needed to expose it at least. Also host for > >> different arches can have some own opts already used that shouldn't be present > >> for cross, better not mix it for safety. > > > >We want -Wmissing-prototypes and -Wstrict-prototypes for cross-compile > >and non-cross-compile cases, right? So let's specify them as common > >set of options, instead of relying on KBUILD_HOSTCFLAGS or > >HOST_EXTRACFLAGS to have them. Otherwise we'll be getting extra > >warnings for just cross-compile case, which is not good. If you are > >worrying about having duplicate -W flags, seems like it's handled by > >GCC already, so shouldn't be a problem. > > Ok, lets drop omit-frame-pointer. > > But then, lets do more radical step and drop > KBUILD_HOSTCFLAGS & HOST_EXTRACFLAG in this patch: Yeah, let's do this, if you confirmed that everything still works (and I don't see a reason why it shouldn't). Thanks. > > -ifdef CROSS_COMPILE > +TPROGS_CFLAGS += -Wall -O2 > +TPROGS_CFLAGS += -Wmissing-prototypes > +TPROGS_CFLAGS += -Wstrict-prototypes > -else > -TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) > -TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) > -endif > > At least it allows to use same options always for both, native and cross. > > I verified on native x86_64, arm64 and arm and cross for arm and arm64, > but should work for others, at least it can be tuned explicitly and > no need to depend on KBUILD and use "cross" fork here. Yep, I like it. > > -- > Regards, > Ivan Khoronzhuk
This series contains mainly fixes/improvements for cross-compilation but not only, tested for arm, arm64, but intended for any arch. Also verified on native build (not cross compilation) for x86_64 and arm. Initial RFC link: https://lkml.org/lkml/2019/8/29/1665 Prev. version: https://lkml.org/lkml/2019/9/10/331 Besides the patches given here, the RFC also contains couple patches related to llvm clang arm: include: asm: swab: mask rev16 instruction for clang arm: include: asm: unified: mask .syntax unified for clang They are necessarily to verify arm build. The change touches not only cross-compilation and can have impact on other archs and build environments, so might be good idea to verify it in order to add appropriate changes, some warn options could be tuned also. All is tested on x86-64 with clang installed (has to be built containing targets for arm, arm64..., see llc --version, usually it's present already) Instructions to test native on x86_64 ================================================= Native build on x86_64 is done in usual way and shouldn't have difference except HOSTCC is now printed as CC wile building the samples. Instructions to test cross compilation on arm64 ================================================= #Toolchain used for test: gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) # Get some arm64 FS, containing at least libelf I've used sdk for TI am65x got here: http://downloads.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07-Linux-x86-Install.bin # Install this binary to some dir, say "sdk". # Configure kernel (use defconfig as no matter), but clean everything # before. make ARCH=arm64 -C tools/ clean make ARCH=arm64 -C samples/bpf clean make ARCH=arm64 clean make ARCH=arm64 defconfig # The kernel version used in sdk doesn't correspond to checked one, # but for this verification only headers need to be syched, # so install them: make ARCH=arm64 headers_install # or on SDK if need keep them in sync (not necessarily to verify): make ARCH=arm64 INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am65xx-evm-06.00.00.07/linux-devkit/sysroots/\ aarch64-linux/usr headers_install # Build samples make samples/bpf/ ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am65xx-evm-06.00.00.07/\ linux-devkit/sysroots/aarch64-linux" Instructions to test cross compilation on arm ================================================= #Toolchains used for test: arm-linux-gnueabihf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 or arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 \ (arm-rel-8.36)) 8.3.0 # Get some FS, I've used sdk for TI am52xx got here: http://downloads.ti.com/processor-sdk-linux/esd/AM57X/05_03_00_07/exports/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07-Linux-x86-Install.bin # Install this binary to some dir, say "sdk". # Configure kernel, but clean everything before. make ARCH=arm -C tools/ clean make ARCH=arm -C samples/bpf clean make ARCH=arm clean make ARCH=arm omap2plus_defconfig # The kernel version used in sdk doesn't correspond to checked one, but headers only should be synched, so install them: make ARCH=arm64 headers_install # or on SDK if need keep them in sync (not necessarily): make ARCH=arm INSTALL_HDR_PATH=/../sdk/\ ti-processor-sdk-linux-am57xx-evm-05.03.00.07/linux-devkit/sysroots/\ armv7ahf-neon-linux-gnueabi/usr headers_install # Build samples make samples/bpf/ ARCH=arm CROSS_COMPILE="arm-linux-gnueabihf-"\ SYSROOT="/../sdk/ti-processor-sdk-linux-am57xx-evm-05.03\ .00.07/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi" Based on bpf-next/master v3..v2: - renamed makefile.progs to makeifle.target, as more appropriate - left only __LINUX_ARM_ARCH__ for D options for arm - for host build - left options from KBUILD_HOST for compatibility reasons - split patch adding c/cxx/ld flags to libbpf by modules - moved readme change to separate patch - added patch setting options for cross-compile - fixed issue with option error for syscall_nrs.S, avoiding overlap for ccflags-y. v2..v1: - restructured patches order - split "samples: bpf: Makefile: base progs build on Makefile.progs" to make change more readable. It added couple nice extra patches. - removed redundant patch: "samples: bpf: Makefile: remove target for native build" - added fix: "samples: bpf: makefile: fix cookie_uid_helper_example obj build" - limited -D option filter only for arm - improved comments - added couple instructions to verify cross compilation for arm and arm64 arches based on TI am57xx and am65xx sdks. - corrected include a little order Ivan Khoronzhuk (14): samples: bpf: makefile: fix HDR_PROBE "echo" samples: bpf: makefile: fix cookie_uid_helper_example obj build samples: bpf: makefile: use --target from cross-compile samples: bpf: use own EXTRA_CFLAGS for clang commands samples: bpf: makefile: use __LINUX_ARM_ARCH__ selector for arm samples: bpf: makefile: drop unnecessarily inclusion for bpf_load samples: bpf: add makefile.target for separate CC target build samples: bpf: makefile: base target programs rules on Makefile.target samples: bpf: makefile: use own flags but not host when cross compile samples: bpf: makefile: use target CC environment for HDR_PROBE libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets samples: bpf: makefile: provide C/CXX/LD flags to libbpf samples: bpf: makefile: add sysroot support samples: bpf: README: add preparation steps and sysroot info samples/bpf/Makefile | 179 +++++++++++++++++++++--------------- samples/bpf/Makefile.target | 75 +++++++++++++++ samples/bpf/README.rst | 41 ++++++++- tools/lib/bpf/Makefile | 11 ++- 4 files changed, 225 insertions(+), 81 deletions(-) create mode 100644 samples/bpf/Makefile.target -- 2.17.1