| Message ID | 20180202162104.2300532-7-arnd@arndb.de |
|---|---|
| State | New |
| Headers | show |
| Series | LTO: hacks to build LTO-enabled randconfig kernels | expand |
On Fri, 2 Feb 2018, Arnd Bergmann wrote: > Building randconfig kernels with a biarch compiler fails with LTO > when the final link uses a different target architecture compared > to the earlier compilation stages. > > Setting -m32 or -m64 in ${LDFINAL} solves this problem, though my > feeling is that there is a better way to do this. There might also > be other from KBUILD_CFLAGS that we may need in LDFINAL. On ARM I had the same problem as it requires explicit arch flags. I therefore used this patch: ----- >8 Subject: [PATCH] LTO: scripts/gcc-ld: LTO on ARM needs arch specific gcc flags Otherwise the final link where code generation happens produces code for the wrong ISA when the default CPU configured into gcc is not the one we need. Also display the actual command when invoked with "make V=1". Signed-off-by: Nicolas Pitre <nico@linaro.org> diff --git a/scripts/gcc-ld b/scripts/gcc-ld index d95dd0be38..fa53be2a34 100755 --- a/scripts/gcc-ld +++ b/scripts/gcc-ld @@ -27,4 +27,10 @@ while [ "$1" != "" ] ; do shift done -exec $CC $ARGS +case "${KBUILD_VERBOSE}" in +*1*) + set -x + ;; +esac + +exec $CC $KBUILD_CFLAGS $ARGS
On Fri, Feb 2, 2018 at 7:41 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Fri, 2 Feb 2018, Arnd Bergmann wrote: > >> Building randconfig kernels with a biarch compiler fails with LTO >> when the final link uses a different target architecture compared >> to the earlier compilation stages. >> >> Setting -m32 or -m64 in ${LDFINAL} solves this problem, though my >> feeling is that there is a better way to do this. There might also >> be other from KBUILD_CFLAGS that we may need in LDFINAL. > > On ARM I had the same problem as it requires explicit arch flags. I > therefore used this patch: > -exec $CC $ARGS > +case "${KBUILD_VERBOSE}" in > +*1*) > + set -x > + ;; > +esac > + > +exec $CC $KBUILD_CFLAGS $ARGS Ah, right, that's much simpler. I'll put that in my test tree now and will see if it works on x86. Do you have a git tree with other changes for LTO on ARM? I'd like to try that as well. Arnd
On Fri, 2 Feb 2018, Arnd Bergmann wrote: > Do you have a git tree with other changes for LTO on ARM? I'd > like to try that as well. I currently have only 2 other patches. You need commit 75fea300d73a that just hit mainline (you may cherry-pick it easily if necessary). Then the following: ----- >8 Subject: [PATCH] HACK: enable LTO on ARM Without the ${KBUILD_VMLINUX_LIBS} move the build fails with missing memcpy all over the place. Didn't figure it out yet. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 4382315005..84450843ed 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -17,6 +17,7 @@ config ARM select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7 select ARCH_SUPPORTS_ATOMIC_RMW + select ARCH_SUPPORTS_LTO select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF select ARCH_WANT_IPC_PARSE_VERSION @@ -101,6 +102,7 @@ config ARM select PERF_USE_VMALLOC select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select THIN_ARCHIVES if LTO # Above selects are sorted alphabetically; please add new ones # according to that. Thanks. help diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index 45a6b9b7af..39ac0a9639 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -97,7 +97,7 @@ targets := vmlinux vmlinux.lds piggy_data piggy.o \ clean-files += piggy_data lib1funcs.S ashldi3.S bswapsdi2.S \ $(libfdt) $(libfdt_hdrs) hyp-stub.S -KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING +KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING $(DISABLE_LTO) ifeq ($(CONFIG_FUNCTION_TRACER),y) ORIG_CFLAGS := $(KBUILD_CFLAGS) diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh index 964b2ee855..0774a87788 100755 --- a/scripts/link-vmlinux.sh +++ b/scripts/link-vmlinux.sh @@ -99,9 +99,9 @@ vmlinux_link() if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then objects="--whole-archive \ built-in.o \ + ${KBUILD_VMLINUX_LIBS} \ --no-whole-archive \ --start-group \ - ${KBUILD_VMLINUX_LIBS} \ --end-group \ ${1}" else > > Arnd >
On Fri, Feb 2, 2018 at 9:38 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > On Fri, 2 Feb 2018, Arnd Bergmann wrote: > >> Do you have a git tree with other changes for LTO on ARM? I'd >> like to try that as well. > > I currently have only 2 other patches. > > You need commit 75fea300d73a that just hit mainline (you may cherry-pick > it easily if necessary). Ok, I apparently have that already by basing on today's linux-next. > Then the following: > > ----- >8 > Subject: [PATCH] HACK: enable LTO on ARM > > Without the ${KBUILD_VMLINUX_LIBS} move the build fails with missing > memcpy all over the place. Didn't figure it out yet. Added that now as well, thanks! I'll see what comes out of it. Have you tried arm64 already? I suppose I could do the same change there and see what happens. Arnd
On Fri, 2 Feb 2018, Arnd Bergmann wrote: > On Fri, Feb 2, 2018 at 9:38 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote: > > On Fri, 2 Feb 2018, Arnd Bergmann wrote: > > > >> Do you have a git tree with other changes for LTO on ARM? I'd > >> like to try that as well. > > > > I currently have only 2 other patches. > > > > You need commit 75fea300d73a that just hit mainline (you may cherry-pick > > it easily if necessary). > > Ok, I apparently have that already by basing on today's linux-next. OK. linux-next has had it for quite a while. > > Then the following: > > > > ----- >8 > > Subject: [PATCH] HACK: enable LTO on ARM > > > > Without the ${KBUILD_VMLINUX_LIBS} move the build fails with missing > > memcpy all over the place. Didn't figure it out yet. > > Added that now as well, thanks! I'll see what comes out of it. I forgot: you'll need to hack your toolchain a bit too. Here's the script I created to remember about the issue: ----- >8 #!/bin/bash # work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78353 GCC_ROOT=/opt/gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf set -e set -x cd $GCC_ROOT//arm-linux-gnueabihf/bin [ -e fat-as ] && exit 1 mv as fat-as cat > as << EOF #!/bin/bash exec -a "\$0" "\$(dirname "\$0")/fat-as" -mimplicit-it=always "\$@" EOF chmod +x as 8< ----- > Have you tried arm64 already? I suppose I could do the same change > there and see what happens. No, didn't try arm64. Nicolas
diff --git a/Makefile b/Makefile index 3b214c5a51a5..1a82fa39f82b 100644 --- a/Makefile +++ b/Makefile @@ -440,7 +440,7 @@ export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL -export KBUILD_ARFLAGS +export KBUILD_ARFLAGS KBUILD_BIARCHFLAGS # When compiling out-of-tree modules, put MODVERDIR in the module # tree rather than in the kernel tree. The kernel tree might diff --git a/arch/x86/Makefile b/arch/x86/Makefile index e79f0fda9aea..12425aafc7fc 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -69,6 +69,7 @@ ifeq ($(CONFIG_X86_32),y) biarch := $(call cc-option,-m32) KBUILD_AFLAGS += $(biarch) KBUILD_CFLAGS += $(biarch) + KBUILD_BIARCHFLAGS += $(biarch) KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return @@ -97,6 +98,7 @@ else biarch := -m64 KBUILD_AFLAGS += -m64 KBUILD_CFLAGS += -m64 + KBUILD_BIARCHFLAGS += $(biarch) # Align jump targets to 1 byte, not the default 16 bytes: KBUILD_CFLAGS += $(call cc-option,-falign-jumps=1) diff --git a/scripts/Makefile.lto b/scripts/Makefile.lto index 2d6995ba7d0b..e57d025b7728 100644 --- a/scripts/Makefile.lto +++ b/scripts/Makefile.lto @@ -72,7 +72,7 @@ endif KBUILD_CFLAGS += ${LTO_CFLAGS} LDFINAL := ${CONFIG_SHELL} ${srctree}/scripts/gcc-ld \ - ${LTO_FINAL_CFLAGS} + ${LTO_FINAL_CFLAGS} ${KBUILD_BIARCHFLAGS} # LTO gcc creates a lot of files in TMPDIR, and with /tmp as tmpfs # it's easy to drive the machine OOM. Use the object directory
Building randconfig kernels with a biarch compiler fails with LTO when the final link uses a different target architecture compared to the earlier compilation stages. Setting -m32 or -m64 in ${LDFINAL} solves this problem, though my feeling is that there is a better way to do this. There might also be other from KBUILD_CFLAGS that we may need in LDFINAL. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- Makefile | 2 +- arch/x86/Makefile | 2 ++ scripts/Makefile.lto | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) -- 2.9.0