[PATCH 0/7] LTO: hacks to build LTO-enabled randconfig kernels

[PATCH 0/7] LTO: hacks to build LTO-enabled randconfig kernels

[Arnd Bergmann]

This is a set of patches that I used for build-testing, resulting
in a successful build without warnings when combining
https://github.com/andikleen/linux-misc#lto-415-2 with the
latest linux-next.

I sent out all bug fixes that I had a good feeling about, this
series is basically crap, but it does the job for me. I'm posting
it for documentation purposes mainly, so we know what some of
the remaining issues are, and so people can google for the
error messages when they run into the same issues.

Arnd Bergmann (7):
  [HACK] lto: make config.gz symbol visible
  [HACK] x86: lto: always link in library files
  [HACK] x86: crypto: fix link error with LTO
  [HACK] lto: shut up some warnings
  [HACK] avoid gcc-8 ICE on LTO
  Kbuild: lto: clean build artifacts
  Kbuild: lto: pass -m32/-m64 to to LDFINAL

 Makefile                   |  2 +-
 arch/x86/Makefile          |  2 ++
 arch/x86/crypto/aes_glue.c |  5 +++++
 arch/x86/lib/Makefile      | 39 ++++++++++++++++++++-------------------
 kernel/Makefile            |  2 +-
 net/sctp/sm_sideeffect.c   |  2 +-
 scripts/Makefile.lto       |  2 +-
 scripts/kallsyms.c         |  2 +-
 scripts/link-vmlinux.sh    |  4 +++-
 scripts/mod/modpost.c      |  4 ++++
 10 files changed, 39 insertions(+), 25 deletions(-)

-- 
2.9.0

[PATCH 0/7] LTO: hacks to build LTO-enabled randconfig kernels

[Arnd Bergmann]

This is a set of patches that I used for build-testing, resulting
in a successful build without warnings when combining
https://github.com/andikleen/linux-misc#lto-415-2 with the
latest linux-next.

I sent out all bug fixes that I had a good feeling about, this
series is basically crap, but it does the job for me. I'm posting
it for documentation purposes mainly, so we know what some of
the remaining issues are, and so people can google for the
error messages when they run into the same issues.

Arnd Bergmann (7):
  [HACK] lto: make config.gz symbol visible
  [HACK] x86: lto: always link in library files
  [HACK] x86: crypto: fix link error with LTO
  [HACK] lto: shut up some warnings
  [HACK] avoid gcc-8 ICE on LTO
  Kbuild: lto: clean build artifacts
  Kbuild: lto: pass -m32/-m64 to to LDFINAL

 Makefile                   |  2 +-
 arch/x86/Makefile          |  2 ++
 arch/x86/crypto/aes_glue.c |  5 +++++
 arch/x86/lib/Makefile      | 39 ++++++++++++++++++++-------------------
 kernel/Makefile            |  2 +-
 net/sctp/sm_sideeffect.c   |  2 +-
 scripts/Makefile.lto       |  2 +-
 scripts/kallsyms.c         |  2 +-
 scripts/link-vmlinux.sh    |  4 +++-
 scripts/mod/modpost.c      |  4 ++++
 10 files changed, 39 insertions(+), 25 deletions(-)

-- 
2.9.0

[PATCH 1/7] [HACK] lto: make config.gz symbol visible

[Arnd Bergmann]

building with LTO enabled, I often get warnings about kernel/configs.c
being empty when CONFIG_IKCONFIG is disabled:

x86_64-linux/bin/nm: kernel/configs.o: no symbols

Making the symbol visible is probably not the right solution, but
it does get rid of the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 kernel/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index 7666ee88e237..40b48e3e87a2 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -120,7 +120,7 @@ targets += config_data.gz
 $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE
 	$(call if_changed,gzip)
 
-      filechk_ikconfiggz = (echo "static const char kernel_config_data[] __used = MAGIC_START"; cat $< | scripts/basic/bin2c; echo "MAGIC_END;")
+      filechk_ikconfiggz = (echo "const char kernel_config_data[] __used __visible = MAGIC_START"; cat $< | scripts/basic/bin2c; echo "MAGIC_END;")
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
 	$(call filechk,ikconfiggz)
-- 
2.9.0

[PATCH 1/7] [HACK] lto: make config.gz symbol visible

[Arnd Bergmann]

building with LTO enabled, I often get warnings about kernel/configs.c
being empty when CONFIG_IKCONFIG is disabled:

x86_64-linux/bin/nm: kernel/configs.o: no symbols

Making the symbol visible is probably not the right solution, but
it does get rid of the warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 kernel/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index 7666ee88e237..40b48e3e87a2 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -120,7 +120,7 @@ targets += config_data.gz
 $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE
 	$(call if_changed,gzip)
 
-      filechk_ikconfiggz = (echo "static const char kernel_config_data[] __used = MAGIC_START"; cat $< | scripts/basic/bin2c; echo "MAGIC_END;")
+      filechk_ikconfiggz = (echo "const char kernel_config_data[] __used __visible = MAGIC_START"; cat $< | scripts/basic/bin2c; echo "MAGIC_END;")
 targets += config_data.h
 $(obj)/config_data.h: $(obj)/config_data.gz FORCE
 	$(call filechk,ikconfiggz)
-- 
2.9.0

[PATCH 2/7] [HACK] x86: lto: always link in library files

[Arnd Bergmann]

Building with LTO on gcc-8, I got many link failures like this:

./ccWpIHzj.ltrans0.ltrans.o: In function `siox_poll_thread':
<artificial>:(.text+0x3042): undefined reference to `memset'
./ccWpIHzj.ltrans0.ltrans.o: In function `iio_push_to_buffers':
<artificial>:(.text+0xdd22): undefined reference to `memcpy'
./ccWpIHzj.ltrans0.ltrans.o: In function `dln2_adc_trigger_h':
<artificial>:(.text+0x24175): undefined reference to `memcpy'
<artificial>:(.text+0x241ec): undefined reference to `memset'
./ccWpIHzj.ltrans3.ltrans.o: In function `ir_update_mapping.isra.1':
<artificial>:(.text+0x1d5a5): undefined reference to `memmove'
./ccWpIHzj.ltrans3.ltrans.o: In function `ir_establish_scancode':
<artificial>:(.text+0x1d6c9): undefined reference to `memmove'
./ccWpIHzj.ltrans9.ltrans.o: In function `write_rbu_image_type':
<artificial>:(.text+0x92d6): undefined reference to `strstr'

It seems that the linker fails to pull in the lib.a file for some
reason I have not found out. We want a proper fix for this, but
in the meantime, this simply makes all those files built-in
all the time, which does the right thing with LTO but might
produce a slightly larger kernel image without it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/lib/Makefile | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 25a972c61b0a..d49f02fd79d6 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -20,32 +20,33 @@ clean-files := inat-tables.c
 
 obj-$(CONFIG_SMP) += msr-smp.o cache-smp.o
 
-lib-y := delay.o misc.o cmdline.o cpu.o
-lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
-lib-y += memcpy_$(BITS).o
-lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
-lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o
-lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
-lib-$(CONFIG_FUNCTION_ERROR_INJECTION)	+= error-inject.o
-lib-$(CONFIG_RETPOLINE) += retpoline.o
+lib-y += delay.o
+obj-y += misc.o cmdline.o cpu.o
+obj-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
+obj-y += memcpy_$(BITS).o
+obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
+obj-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o
+obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
+obj-$(CONFIG_FUNCTION_ERROR_INJECTION)	+= error-inject.o
+obj-$(CONFIG_RETPOLINE) += retpoline.o
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
 
 ifeq ($(CONFIG_X86_32),y)
         obj-y += atomic64_32.o
-        lib-y += atomic64_cx8_32.o
-        lib-y += checksum_32.o
-        lib-y += strstr_32.o
-        lib-y += string_32.o
+        obj-y += atomic64_cx8_32.o
+        obj-y += checksum_32.o
+        obj-y += strstr_32.o
+        obj-y += string_32.o
 ifneq ($(CONFIG_X86_CMPXCHG64),y)
-        lib-y += cmpxchg8b_emu.o atomic64_386_32.o
+        obj-y += cmpxchg8b_emu.o atomic64_386_32.o
 endif
-        lib-$(CONFIG_X86_USE_3DNOW) += mmx_32.o
+        obj-$(CONFIG_X86_USE_3DNOW) += mmx_32.o
 else
         obj-y += iomap_copy_64.o
-        lib-y += csum-partial_64.o csum-copy_64.o csum-wrappers_64.o
-        lib-y += clear_page_64.o copy_page_64.o
-        lib-y += memmove_64.o memset_64.o
-        lib-y += copy_user_64.o
-	lib-y += cmpxchg16b_emu.o
+        obj-y += csum-partial_64.o csum-copy_64.o csum-wrappers_64.o
+        obj-y += clear_page_64.o copy_page_64.o
+        obj-y += memmove_64.o memset_64.o
+        obj-y += copy_user_64.o
+	obj-y += cmpxchg16b_emu.o
 endif
-- 
2.9.0

[PATCH 3/7] [HACK] x86: crypto: fix link error with LTO

[Arnd Bergmann]

crypto_it_tab and the other symbols like it are defined in
crypto/aes_generic.c and exported for loadable modules. When
building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports
are eliminated, since kbuild fails to take the users in
the arch/x86/crypto/aes-i586-asm_32.S assembler file into
account.

This adds an ugly workaround by adding a reference to each symbol
into aes_glue.c, which gets linked together with the assembler
file.

We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic
to do the right thing here instead, but I couldn't come up
with a good fix, so I use this instead to get a clean build
for testing.

This fix only works most of the time, but I still ran into
some cases where combining an .S with a .c file did not
produce the correct .ko file, as the lto linker apparently
did not expect that kind of input. 'nm' on the file after
'ld -r' showed only the contents of the assembler file, and
after the lto-ld stage, only the contents of the .c file
are there.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/crypto/aes_glue.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/crypto/aes_glue.c b/arch/x86/crypto/aes_glue.c
index e26984f7ab8d..6da3e3c34a77 100644
--- a/arch/x86/crypto/aes_glue.c
+++ b/arch/x86/crypto/aes_glue.c
@@ -53,6 +53,11 @@ static struct crypto_alg aes_alg = {
 
 static int __init aes_init(void)
 {
+	/* ugly hack to force a link time dependency */
+	if (&crypto_it_tab == &crypto_ft_tab ||
+	    &crypto_fl_tab == &crypto_il_tab)
+		return 0;
+
 	return crypto_register_alg(&aes_alg);
 }
 
-- 
2.9.0

Re: [PATCH 3/7] [HACK] x86: crypto: fix link error with LTO

[Nicolas Pitre]

On Fri, 2 Feb 2018, Arnd Bergmann wrote:

> crypto_it_tab and the other symbols like it are defined in
> crypto/aes_generic.c and exported for loadable modules. When
> building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports
> are eliminated, since kbuild fails to take the users in
> the arch/x86/crypto/aes-i586-asm_32.S assembler file into
> account.
> 
> This adds an ugly workaround by adding a reference to each symbol
> into aes_glue.c, which gets linked together with the assembler
> file.
> 
> We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic
> to do the right thing here instead, but I couldn't come up
> with a good fix, so I use this instead to get a clean build
> for testing.

Could you give me the .config you used for this? So far I can't 
reproduce, and guessing with LTO takes lots of time.

> This fix only works most of the time, but I still ran into
> some cases where combining an .S with a .c file did not
> produce the correct .ko file, as the lto linker apparently
> did not expect that kind of input. 'nm' on the file after
> 'ld -r' showed only the contents of the assembler file, and
> after the lto-ld stage, only the contents of the .c file
> are there.

'ld -r' does not support mixed (LTO and non-LTO) objects.


Nicolas

Re: [PATCH 3/7] [HACK] x86: crypto: fix link error with LTO

[Arnd Bergmann]

On Fri, Feb 2, 2018 at 8:49 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 2 Feb 2018, Arnd Bergmann wrote:
>
>> crypto_it_tab and the other symbols like it are defined in
>> crypto/aes_generic.c and exported for loadable modules. When
>> building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports
>> are eliminated, since kbuild fails to take the users in
>> the arch/x86/crypto/aes-i586-asm_32.S assembler file into
>> account.
>>
>> This adds an ugly workaround by adding a reference to each symbol
>> into aes_glue.c, which gets linked together with the assembler
>> file.
>>
>> We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic
>> to do the right thing here instead, but I couldn't come up
>> with a good fix, so I use this instead to get a clean build
>> for testing.
>
> Could you give me the .config you used for this? So far I can't
> reproduce, and guessing with LTO takes lots of time.

I've uploaded my randconfig file to

https://pastebin.com/raw/iLk4sSpw

>> This fix only works most of the time, but I still ran into
>> some cases where combining an .S with a .c file did not
>> produce the correct .ko file, as the lto linker apparently
>> did not expect that kind of input. 'nm' on the file after
>> 'ld -r' showed only the contents of the assembler file, and
>> after the lto-ld stage, only the contents of the .c file
>> are there.
>
> 'ld -r' does not support mixed (LTO and non-LTO) objects.

Ok, that would explain it. I checked that CONFIG_THIN_ARCHIVES
is set here, but I see clearly that the module is linked using

x86_64-linux-ld -m elf_x86_64   -r -o arch/x86/crypto/aes-x86_64.o
arch/x86/crypto/aes-x86_64-asm_64.o arch/x86/crypto/aes_glue.o ;
scripts/mod/modpost arch/x86/crypto/aes-x86_64.o

       Arnd

[PATCH 4/7] [HACK] lto: shut up some warnings

[Arnd Bergmann]

Building with LTO currently causes some annoying warnings:

WARNING: modpost: missing MODULE_LICENSE() in drivers/vhost/vhost_scsi.o
see include/linux/module.h for more information
kallsyms failure: relative symbol value 0xffffffff81000000 out of range in relative mode

The modpost warning is a false-positive, the other one is so far
unknown. Both need a proper fix.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/kallsyms.c    | 2 +-
 scripts/mod/modpost.c | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 9ee9bf7fd1a2..e13227898d0b 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -395,7 +395,7 @@ static void write_src(void)
 				offset = relative_base - table[i].addr - 1;
 				overflow = (offset < INT_MIN || offset >= 0);
 			}
-			if (overflow) {
+			if (0 && overflow) {
 				fprintf(stderr, "kallsyms failure: "
 					"%s symbol value %#llx out of range in relative mode\n",
 					symbol_absolute(&table[i]) ? "absolute" : "relative",
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 49dfcd556c78..87c4404dad48 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -867,6 +867,7 @@ static const char *const section_white_list[] =
 static void check_section(const char *modname, struct elf_info *elf,
 			  Elf_Shdr *sechdr)
 {
+#if 0
 	const char *sec = sech_name(elf, sechdr);
 
 	if (sechdr->sh_type == SHT_PROGBITS &&
@@ -878,6 +879,7 @@ static void check_section(const char *modname, struct elf_info *elf,
 		     "section definitions for use in .S files.\n\n",
 		     modname, sec);
 	}
+#endif
 }
 
 
@@ -1963,10 +1965,12 @@ static void read_symbols(char *modname)
 	}
 
 	license = get_modinfo(info.modinfo, info.modinfo_len, "license");
+#if 0
 	if (!license && !is_vmlinux(modname))
 		warn("modpost: missing MODULE_LICENSE() in %s\n"
 		     "see include/linux/module.h for "
 		     "more information\n", modname);
+#endif
 	while (license) {
 		if (license_is_gpl_compatible(license))
 			mod->gpl_compatible = 1;
-- 
2.9.0

[PATCH 5/7] [HACK] avoid gcc-8 ICE on LTO

[Arnd Bergmann]

I ran into a build error:

/git/arm-soc/net/sctp/sm_sideeffect.c: In function 'sctp_do_sm':
/git/arm-soc/net/sctp/sm_sideeffect.c:1155:5: internal compiler error: Segmentation fault
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
     ^
0xa42b7f crash_signal

The bug is fixed in mainline gcc now, but I carry this as I have
not yet upgrade.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/sctp/sm_sideeffect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index b71e7fb0a20a..d211863fad48 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1152,12 +1152,12 @@ static void sctp_cmd_send_asconf(struct sctp_association *asoc)
  * If you want to understand all of lksctp, this is a
  * good place to start.
  */
+typedef const char *(printfn_t)(union sctp_subtype);
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
 	       union sctp_subtype subtype, enum sctp_state state,
 	       struct sctp_endpoint *ep, struct sctp_association *asoc,
 	       void *event_arg, gfp_t gfp)
 {
-	typedef const char *(printfn_t)(union sctp_subtype);
 	static printfn_t *table[] = {
 		NULL, sctp_cname, sctp_tname, sctp_oname, sctp_pname,
 	};
-- 
2.9.0

Re: [PATCH 5/7] [HACK] avoid gcc-8 ICE on LTO

[Joe Perches]

On Fri, 2018-02-02 at 17:21 +0100, Arnd Bergmann wrote:
> I ran into a build error:
> 
> /git/arm-soc/net/sctp/sm_sideeffect.c: In function 'sctp_do_sm':
> /git/arm-soc/net/sctp/sm_sideeffect.c:1155:5: internal compiler error: Segmentation fault
>  int sctp_do_sm(struct net *net, enum sctp_event event_type,
>      ^
> 0xa42b7f crash_signal
> 
> The bug is fixed in mainline gcc now, but I carry this as I have
> not yet upgrade.
[]
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
[]
> @@ -1152,12 +1152,12 @@ static void sctp_cmd_send_asconf(struct sctp_association *asoc)
>   * If you want to understand all of lksctp, this is a
>   * good place to start.
>   */
> +typedef const char *(printfn_t)(union sctp_subtype);

This typedef is only used in this file twice.
Perhaps removing the typedef is clearer.

Given the debug_fn use is only in another
used-once macro, convert that debug_fn in
the macro too and avoid the unnecessary
variable initialization.

The debug_[pre|post]_[sfn|sfx] macros are
probably unnecessary indirections and could
be removed too but the code might read worse.

---
 net/sctp/sm_sideeffect.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index b71e7fb0a20a..5a6de0070b71 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1133,8 +1133,9 @@ static void sctp_cmd_send_asconf(struct sctp_association *asoc)
  * functionality there.
  */
 #define debug_pre_sfn() \
-	pr_debug("%s[pre-fn]: ep:%p, %s, %s, asoc:%p[%s], %s\n", __func__, \
-		 ep, sctp_evttype_tbl[event_type], (*debug_fn)(subtype),   \
+	pr_debug("%s[pre-fn]: ep:%p, %s, %s, asoc:%p[%s], %s\n",	\
+		 __func__, ep, sctp_evttype_tbl[event_type],		\
+		 (*table[event_type])(subtype),				\
 		 asoc, sctp_state_tbl[state], state_fn->name)
 
 #define debug_post_sfn() \
@@ -1157,11 +1158,9 @@ int sctp_do_sm(struct net *net, enum sctp_event event_type,
 	       struct sctp_endpoint *ep, struct sctp_association *asoc,
 	       void *event_arg, gfp_t gfp)
 {
-	typedef const char *(printfn_t)(union sctp_subtype);
-	static printfn_t *table[] = {
+	static const char *(*table[])(union sctp_subtype) = {
 		NULL, sctp_cname, sctp_tname, sctp_oname, sctp_pname,
 	};
-	printfn_t *debug_fn  __attribute__ ((unused)) = table[event_type];
 	const struct sctp_sm_table_entry *state_fn;
 	struct sctp_cmd_seq commands;
 	enum sctp_disposition status;

[PATCH 6/7] Kbuild: lto: clean build artifacts

[Arnd Bergmann]

During test-building I filled up my disk with stale files
that never got cleaned. This should make sure we remove them
all.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 scripts/link-vmlinux.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 964b2ee855dd..130df0781072 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -113,7 +113,7 @@ vmlinux_link()
 				${1}"
 		fi
 
-		${LDFINAL} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2}		\
+		${LDFINAL} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2}	\
 			-T ${lds} ${objects}
 	else
 		if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
@@ -195,6 +195,8 @@ cleanup()
 	rm -f System.map
 	rm -f vmlinux
 	rm -f vmlinux.o
+	rm -f cc*.ltrans*.o
+	rm -f vmlinux.o.* vmlinux.ltrans* vmlinux.wpa*
 }
 
 on_exit()
-- 
2.9.0

[PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Arnd Bergmann]

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(-)

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
-- 
2.9.0

Re: [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Nicolas Pitre]

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

Re: [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Arnd Bergmann]

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

Re: [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Nicolas Pitre]

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
> 

Re: [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Arnd Bergmann]

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

Re: [PATCH 7/7] Kbuild: lto: pass -m32/-m64 to to LDFINAL

[Nicolas Pitre]

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