[v3,bpf-next,00/14] samples: bpf: improve/fix cross-compilation

Message ID 20190916105433.11404-1-ivan.khoronzhuk@linaro.org
Headers show
Series
  • samples: bpf: improve/fix cross-compilation
Related show

Message

Ivan Khoronzhuk Sept. 16, 2019, 10:54 a.m.
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

Comments

Andrii Nakryiko Sept. 16, 2019, 8:25 p.m. | #1
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

>
Andrii Nakryiko Sept. 16, 2019, 8:35 p.m. | #2
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

>
Sergei Shtylyov Sept. 17, 2019, 10:14 a.m. | #3
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
Andrii Nakryiko Sept. 17, 2019, 11:42 p.m. | #4
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

>
Andrii Nakryiko Sept. 18, 2019, 4:20 a.m. | #5
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>



[...]
Andrii Nakryiko Sept. 18, 2019, 5:33 a.m. | #6
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

>
Ivan Khoronzhuk Sept. 18, 2019, 10:35 a.m. | #7
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
Andrii Nakryiko Sept. 18, 2019, 9:29 p.m. | #8
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
Ivan Khoronzhuk Sept. 19, 2019, 2:18 p.m. | #9
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
Andrii Nakryiko Sept. 19, 2019, 5:54 p.m. | #10
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