[PATCH 00/15] Add support for clang LTO

[PATCH 00/15] Add support for clang LTO

[Sami Tolvanen]

This series adds build system support for compiling the kernel with clang
Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in
for linking. Some background for clang's LTO support is available here:

  https://llvm.org/docs/LinkTimeOptimization.html

With -flto, clang produces LLVM bitcode instead of object files, and
the compilation to native code happens at link time. In addition, clang
cannot use an external assembler for inline assembly when LTO is enabled,
which causes further compatibility issues.

The patches in this series remove intermediate linking steps when LTO is
used, postpone processing done on object files until after the LTO link
step, add workarounds for GNU gold incompatibilities, and address inline
assembly incompatibilities for arm64.

These changes allow arm64 defconfig to be compiled with LTO, but other
architectures are not enabled until compatibility issues have been
addressed. In particular, x86 inline assembly doesn't currently compile
with clang's integrated assembler due to this LLVM bug:

  https://bugs.llvm.org/show_bug.cgi?id=24487

Due to recent bug fixes in the toolchain, it's recommended to use clang
5.0 or later, and GNU gold from binutils 2.27 or later, although older
versions may also work depending on your kernel configuration. Here are
the steps for compiling arm64 defconfig with LTO, assuming LLVMgold.so is
in LD_LIBRARY_PATH and the rest of the toolchain is in PATH:

  $ make ARCH=arm64 defconfig
  $ ./scripts/config -e CLANG_LTO
  $ make ARCH=arm64 oldconfig
  $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang \
         LD=aarch64-linux-gnu-ld.gold

You can also define LD_FINAL_VMLINUX to use a different linker for
vmlinux_link, which may be necessary for working around GNU gold issues
with KASLR, for example.

Greg Hackmann (1):
  arm64: use -mno-implicit-float instead of -mgeneral-regs-only

Sami Tolvanen (14):
  kbuild: add ld-name macro and support for GNU gold
  kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION with GNU gold
  kbuild: add support for clang LTO
  kbuild: fix dynamic ftrace with clang LTO
  scripts/mod: disable LTO for empty.c
  efi/libstub: disable clang LTO
  arm64: don't pass -maarch64linux to GNU gold
  arm64: keep .altinstructions and .altinstr_replacement
  arm64: disable ARM64_ERRATUM_843419 for clang LTO
  arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold
  arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS
  arm64: fix mrs_s/msr_s macros for clang LTO
  arm64: crypto: disable LTO for aes-ce-cipher.c
  arm64: select ARCH_SUPPORTS_CLANG_LTO

 .gitignore                            |   2 +
 Makefile                              |  21 ++++++-
 arch/Kconfig                          |  32 ++++++++++
 arch/arm64/Kconfig                    |   6 +-
 arch/arm64/Makefile                   |  17 +++++-
 arch/arm64/crypto/Makefile            |   2 +-
 arch/arm64/include/asm/kvm_hyp.h      |   2 +
 arch/arm64/include/asm/sysreg.h       |  71 ++++++++++++++++------
 arch/arm64/kernel/vmlinux.lds.S       |   4 +-
 drivers/firmware/efi/libstub/Makefile |   3 +-
 include/asm-generic/vmlinux.lds.h     |  10 ++--
 include/linux/compiler-clang.h        |   7 +++
 include/linux/compiler.h              |   4 ++
 kernel/trace/ftrace.c                 |   6 +-
 scripts/Kbuild.include                |   4 ++
 scripts/Makefile.build                |  83 +++++++++++++++++++++++++-
 scripts/Makefile.modpost              |  67 ++++++++++++++++++---
 scripts/link-vmlinux.sh               | 108 ++++++++++++++++++++++++++++++----
 scripts/mod/Makefile                  |   1 +
 scripts/recordmcount.c                |   3 +-
 20 files changed, 397 insertions(+), 56 deletions(-)

-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 01/15] kbuild: add ld-name macro and support for GNU gold

[Sami Tolvanen]

GNU gold may require different flags than GNU ld. Add a macro for
detecting the linker and conditionally add gold specific flags from
LDFLAGS_GOLD.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 Makefile               | 5 +++++
 scripts/Kbuild.include | 4 ++++
 2 files changed, 9 insertions(+)

diff --git a/Makefile b/Makefile
index 3a8868ee967e..59980d5a03d0 100644
--- a/Makefile
+++ b/Makefile
@@ -826,6 +826,11 @@ include scripts/Makefile.kasan
 include scripts/Makefile.extrawarn
 include scripts/Makefile.ubsan
 
+# Add any flags specific to ld.gold
+ifeq ($(ld-name),gold)
+LDFLAGS		+= $(LDFLAGS_GOLD)
+endif
+
 # Add any arch overrides and user supplied CPPFLAGS, AFLAGS and CFLAGS as the
 # last assignments
 KBUILD_CPPFLAGS += $(ARCH_CPPFLAGS) $(KCPPFLAGS)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 9ffd3dda3889..584d6cecd7c0 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -172,6 +172,10 @@ ld-option = $(call try-run,\
 # Important: no spaces around options
 ar-option = $(call try-run, $(AR) rc$(1) "$$TMP",$(1),$(2))
 
+# ld-name
+# Expands to either bfd or gold
+ld-name = $(shell $(LD) -v 2>&1 | grep -q "GNU gold" && echo gold || echo bfd)
+
 # ld-version
 # Note this is mainly for HJ Lu's 3 number binutil versions
 ld-version = $(shell $(LD) --version | $(srctree)/scripts/ld-version.sh)
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 01/15] kbuild: add ld-name macro and support for GNU gold

[Nick Desaulniers]

+ Kbuild mailing list and maintainers

The use of these ternary like operations will need to be expanded if
additional compilers come along (less likely), or additional linkers
(more likely, we are looking into lld right now) but we can cross that
bridge when we get there.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

On Fri, Nov 3, 2017 at 10:11 AM, Sami Tolvanen <samitolvanen@google.com> wrote:
> GNU gold may require different flags than GNU ld. Add a macro for
> detecting the linker and conditionally add gold specific flags from
> LDFLAGS_GOLD.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  Makefile               | 5 +++++
>  scripts/Kbuild.include | 4 ++++
>  2 files changed, 9 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 3a8868ee967e..59980d5a03d0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,6 +826,11 @@ include scripts/Makefile.kasan
>  include scripts/Makefile.extrawarn
>  include scripts/Makefile.ubsan
>
> +# Add any flags specific to ld.gold
> +ifeq ($(ld-name),gold)
> +LDFLAGS                += $(LDFLAGS_GOLD)
> +endif
> +
>  # Add any arch overrides and user supplied CPPFLAGS, AFLAGS and CFLAGS as the
>  # last assignments
>  KBUILD_CPPFLAGS += $(ARCH_CPPFLAGS) $(KCPPFLAGS)
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index 9ffd3dda3889..584d6cecd7c0 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -172,6 +172,10 @@ ld-option = $(call try-run,\
>  # Important: no spaces around options
>  ar-option = $(call try-run, $(AR) rc$(1) "$$TMP",$(1),$(2))
>
> +# ld-name
> +# Expands to either bfd or gold
> +ld-name = $(shell $(LD) -v 2>&1 | grep -q "GNU gold" && echo gold || echo bfd)
> +
>  # ld-version
>  # Note this is mainly for HJ Lu's 3 number binutil versions
>  ld-version = $(shell $(LD) --version | $(srctree)/scripts/ld-version.sh)
> --
> 2.15.0.403.gc27cc4dac6-goog
>



-- 
Thanks,
~Nick Desaulniers

[PATCH 02/15] kbuild: fix LD_DEAD_CODE_DATA_ELIMINATION with GNU gold

[Sami Tolvanen]

Don't remove .head.text or .exitcall.exit when linking with --gc-sections,
and include .init.text.* in .init.text and .init.rodata.* in .init.rodata.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/asm-generic/vmlinux.lds.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 8acfc1e099e1..d0070985c191 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -511,7 +511,7 @@
 		VMLINUX_SYMBOL(__softirqentry_text_end) = .;
 
 /* Section used for early init (in .S files) */
-#define HEAD_TEXT  *(.head.text)
+#define HEAD_TEXT  KEEP(*(.head.text))
 
 #define HEAD_TEXT_SECTION							\
 	.head.text : AT(ADDR(.head.text) - LOAD_OFFSET) {		\
@@ -556,7 +556,7 @@
 	MEM_DISCARD(init.data)						\
 	KERNEL_CTORS()							\
 	MCOUNT_REC()							\
-	*(.init.rodata)							\
+	*(.init.rodata .init.rodata.*)					\
 	FTRACE_EVENTS()							\
 	TRACE_SYSCALLS()						\
 	KPROBE_BLACKLIST()						\
@@ -575,7 +575,7 @@
 	EARLYCON_TABLE()
 
 #define INIT_TEXT							\
-	*(.init.text)							\
+	*(.init.text .init.text.*)					\
 	*(.text.startup)						\
 	MEM_DISCARD(init.text)
 
@@ -592,7 +592,7 @@
 	MEM_DISCARD(exit.text)
 
 #define EXIT_CALL							\
-	*(.exitcall.exit)
+	KEEP(*(.exitcall.exit))
 
 /*
  * bss (Block Started by Symbol) - uninitialized data
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 03/15] kbuild: add support for clang LTO

[Sami Tolvanen]

This change adds the configuration option CONFIG_CLANG_LTO, and build
system support for clang's Link Time Optimization (LTO).

With -flto, instead of object files, clang produces LLVM bitcode,
which is compiled into a native object at link time, allowing the
final binary to be optimized globally. For more details, see:

  https://llvm.org/docs/LinkTimeOptimization.html

While the kernel normally uses GNU ld for linking, LLVM supports LTO
only with gold or lld linkers. This patch set assumes GNU gold will be
used with the LLVMgold plug-in to perform the LTO link step. Due to
potential incompatibilities with GNU ld, we also add LD_FINAL_VMLINUX
environment variable for specifying a different linker to be used for
the vmlinux_link step.

Here's an example command line for building the kernel with LTO, with
the assumption that LLVMgold.so is in LD_LIBRARY_PATH:

  $ make CC=clang LD=ld.gold LD_FINAL_VMLINUX=ld

Recommended versions are >= 5.0 for clang, and >= 2.27 for binutils.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 .gitignore               |  2 ++
 Makefile                 | 16 ++++++++-
 arch/Kconfig             | 32 +++++++++++++++++
 scripts/Makefile.build   | 69 ++++++++++++++++++++++++++++++++++--
 scripts/Makefile.modpost | 63 ++++++++++++++++++++++++++++-----
 scripts/link-vmlinux.sh  | 92 ++++++++++++++++++++++++++++++++++++++++++------
 6 files changed, 252 insertions(+), 22 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0c39aa20b6ba..7c2db278556e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,6 +13,7 @@
 *.o
 *.o.*
 *.a
+*.a.*
 *.s
 *.ko
 *.so
@@ -39,6 +40,7 @@ Module.symvers
 *.dwo
 *.su
 *.c.[012]*.*
+*.modversions
 
 #
 # Top-level generic files
diff --git a/Makefile b/Makefile
index 59980d5a03d0..01202b53b995 100644
--- a/Makefile
+++ b/Makefile
@@ -788,6 +788,17 @@ KBUILD_CFLAGS	+= $(call cc-option,-ffunction-sections,)
 KBUILD_CFLAGS	+= $(call cc-option,-fdata-sections,)
 endif
 
+ifdef CONFIG_CLANG_LTO
+KBUILD_CFLAGS	+= -flto -fvisibility=hidden
+LDFLAGS_GOLD	+= -plugin LLVMgold.so
+DISABLE_LTO	:= -fno-lto
+export DISABLE_LTO LD_FINAL_VMLINUX LDFLAGS_FINAL_VMLINUX
+ifdef CONFIG_MODVERSIONS
+LLVM_DIS	:= llvm-dis
+export LLVM_DIS
+endif
+endif
+
 # arch Makefile may override CC so keep this after arch Makefile is included
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS     += $(NOSTDINC_FLAGS)
@@ -1562,7 +1573,10 @@ clean: $(clean-dirs)
 		-o -name modules.builtin -o -name '.tmp_*.o.*' \
 		-o -name '*.c.[012]*.*' \
 		-o -name '*.ll' \
-		-o -name '*.gcno' \) -type f -print | xargs rm -f
+		-o -name '*.gcno' \
+		-o -name '*.[oa].objects' \
+		-o -name '*.o.symversions' \
+		-o -name '*.modversions' \) -type f -print | xargs rm -f
 
 # Generate tags for editors
 # ---------------------------------------------------------------------------
diff --git a/arch/Kconfig b/arch/Kconfig
index 057370a0ac4e..6b0c9d4de369 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -585,6 +585,7 @@ config CC_STACKPROTECTOR_STRONG
 endchoice
 
 config THIN_ARCHIVES
+	depends on !CLANG_LTO
 	def_bool y
 	help
 	  Select this if the architecture wants to use thin archives
@@ -605,6 +606,37 @@ config LD_DEAD_CODE_DATA_ELIMINATION
 	  sections (e.g., '.text.init'). Typically '.' in section names
 	  is used to distinguish them from label names / C identifiers.
 
+config ARCH_SUPPORTS_CLANG_LTO
+	bool
+	help
+	  An architecture should select this option it supports:
+	  - compiling with clang,
+	  - compiling inline assembly with clang's integrated assembler,
+	  - and linking with either lld or GNU gold w/ LLVMgold.
+
+config CLANG_LTO
+	bool "Use clang Link Time Optimization (LTO)"
+	depends on ARCH_SUPPORTS_CLANG_LTO
+	depends on !FTRACE_MCOUNT_RECORD
+	select LD_DEAD_CODE_DATA_ELIMINATION
+	help
+          This option enables clang's Link Time Optimization (LTO), which allows
+          the compiler to optimize the kernel globally at link time. If you
+          enable this option, the compiler generates LLVM IR instead of object
+          files, and the actual compilation from IR occurs at the LTO link step,
+          which may take several minutes.
+
+          If you select this option, you must compile the kernel with clang
+          (CC=clang) and use either lld, or GNU gold with the LLVMgold plug-in,
+          as the linker (e.g. LD=ld.gold). Note that if you use gold, the
+          LLVMgold plug-in must be in LD_LIBRARY_PATH. Depending on your linker
+          version, you may need to use GNU ld to link the final vmlinux by
+          setting LD_FINAL_VMLINUX=ld.
+
+          Using clang >= 5.0 and GNU gold from binutils >= 2.27 is recommended
+          for this option.
+
+
 config HAVE_ARCH_WITHIN_STACK_FRAMES
 	bool
 	help
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index bb831d49bcfd..0cff240454f8 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -210,6 +210,23 @@ else
 
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
 
+ifdef CONFIG_CLANG_LTO
+# Generate .o.symversions files for each .o with exported symbols, and link these
+# to the kernel and/or modules at the end.
+cmd_modversions_c =								\
+	if echo '$(c_flags)' | grep -q -- '$(DISABLE_LTO)'; then		\
+		if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then	\
+			$(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes)) \
+			    > $(@D)/$(@F).symversions;				\
+		fi;								\
+	else									\
+		if $(LLVM_DIS) -o=- $(@D)/.tmp_$(@F) | grep -q __ksymtab; then	\
+			$(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes)) \
+			    > $(@D)/$(@F).symversions;				\
+		fi;								\
+	fi;									\
+	mv -f $(@D)/.tmp_$(@F) $@;
+else
 cmd_modversions_c =								\
 	if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then		\
 		$(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))	\
@@ -222,6 +239,7 @@ cmd_modversions_c =								\
 		mv -f $(@D)/.tmp_$(@F) $@;					\
 	fi;
 endif
+endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
 ifdef BUILD_C_RECORDMCOUNT
@@ -443,6 +461,13 @@ $(obj)/%-asn1.c $(obj)/%-asn1.h: $(src)/%.asn1 $(objtree)/scripts/asn1_compiler
 # To build objects in subdirs, we need to descend into the directories
 $(sort $(subdir-obj-y)): $(subdir-ym) ;
 
+ifdef CONFIG_CLANG_LTO
+# If LTO is enabled, we remove all intermediate linking steps and instead
+# collect a list of all objects to be linked at the end.
+cc_lto_objects = $(foreach o,$(1),\
+			[ -f ${o}.objects ] && cat ${o}.objects || echo ${o};)
+endif
+
 #
 # Rule to compile a set of .o files into one .o file
 #
@@ -458,6 +483,17 @@ else
   quiet_cmd_link_o_target = LD      $@
 endif
 
+ifdef CONFIG_CLANG_LTO
+builtin-cmds = $(call cc_lto_objects,$(filter $(obj-y), $^))
+
+quiet_cmd_update_builtin = GEN     $@
+cmd_update_builtin = (cat /dev/null; $(builtin-cmds)) > $@.objects && \
+			cat /dev/null > $@
+
+$(builtin-target): $(obj-y) FORCE
+	$(call if_changed,update_builtin)
+else
+quiet_cmd_link_o_target = LD      $@
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $(obj-y)),\
 		      $(cmd_make_builtin) $@ $(filter $(obj-y), $^) \
@@ -466,6 +502,7 @@ cmd_link_o_target = $(if $(strip $(obj-y)),\
 
 $(builtin-target): $(obj-y) FORCE
 	$(call if_changed,link_o_target)
+endif
 
 targets += $(builtin-target)
 endif # builtin-target
@@ -487,6 +524,16 @@ $(modorder-target): $(subdir-ym) FORCE
 # Rule to compile a set of .o files into one .a file
 #
 ifdef lib-target
+ifdef CONFIG_CLANG_LTO
+lib-target-cmds = $(call cc_lto_objects,$(lib-y))
+
+quiet_cmd_update_lib_target = GEN     $@
+cmd_update_lib_target = (cat /dev/null; $(lib-target-cmds)) > $@.objects && \
+			cat /dev/null > $@
+
+$(lib-target): $(lib-y) FORCE
+	$(call if_changed,update_lib_target)
+else
 quiet_cmd_link_l_target = AR      $@
 
 ifdef CONFIG_THIN_ARCHIVES
@@ -497,6 +544,7 @@ endif
 
 $(lib-target): $(lib-y) FORCE
 	$(call if_changed,link_l_target)
+endif
 
 targets += $(lib-target)
 
@@ -552,15 +600,32 @@ endif
 quiet_cmd_link_multi-m = LD [M]  $@
 cmd_link_multi-m = $(cmd_link_multi-link)
 
+ifdef CONFIG_CLANG_LTO
+multi-deps-cmds = $(call cc_lto_objects,$(link_multi_deps))
+
+quiet_cmd_update_multi_deps = GEN     $@
+cmd_update_multi_deps = (cat /dev/null; $(multi-deps-cmds)) > $@.objects && \
+			cat /dev/null > $@
+
+$(multi-used-y): FORCE
+	$(call if_changed,update_multi_deps)
+
+$(multi-used-m): FORCE
+	$(call if_changed,update_multi_deps)
+	@{ echo $(@:.o=.ko); echo $(link_multi_deps); \
+	   $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
+else
 $(multi-used-y): FORCE
 	$(call if_changed,link_multi-y)
-$(call multi_depend, $(multi-used-y), .o, -objs -y)
 
 $(multi-used-m): FORCE
 	$(call if_changed,link_multi-m)
 	@{ echo $(@:.o=.ko); echo $(link_multi_deps); \
 	   $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
-$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
+endif
+
+$(call multi_depend, $(multi-used-y), .o, -objs -y)
+$(call multi_depend, $(multi-used-m), .o, -objs -y)
 
 targets += $(multi-used-y) $(multi-used-m)
 
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 991db7d6e4df..2f3b45cbbe6b 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -83,12 +83,46 @@ modpost = scripts/mod/modpost                    \
 
 MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
 
+# If CONFIG_CLANG_LTO is enabled, .o files are either LLVM IR, or empty, so we
+# need to link them into actual objects before passing them to modpost
+modpost-ext = $(if $(CONFIG_CLANG_LTO),.lto,)
+
+ifdef CONFIG_CLANG_LTO
+quiet_cmd_cc_lto_modversions = GEN [M]  $@
+cmd_cc_lto_modversions = 						\
+	rm -f $(@); 							\
+	if [ -f $(@:.modversions=.o).objects ]; then 			\
+		for i in `cat $(@:.modversions=.o).objects`; do 	\
+			[ -s $$i.symversions ] &&			\
+				cat $$i.symversions >> $(@);		\
+		done;							\
+	else								\
+		[ -s $(@:.modversions=.o).symversions ] &&		\
+			cat $(@:.modversions=.o).symversions >> $(@);	\
+	fi
+
+$(modules:.ko=.modversions): FORCE
+	$(call if_changed,cc_lto_modversions)
+
+quiet_cmd_cc_lto_link_modules = LD [M]  $@
+cmd_cc_lto_link_modules =						\
+	$(LD) $(ld_flags) -r -o $(@)					\
+		$(shell [ -s $(@:$(modpost-ext).o=.modversions) ] &&	\
+			echo -T $(@:$(modpost-ext).o=.modversions))	\
+		$(shell [ -f $(@:$(modpost-ext).o=.o).objects ] &&	\
+			 cat $(@:$(modpost-ext).o=.o).objects ||	\
+			echo $(@:$(modpost-ext).o=.o))
+
+$(modules:.ko=$(modpost-ext).o): %$(modpost-ext).o: %.o %.modversions FORCE
+	$(call if_changed,cc_lto_link_modules)
+endif
+
 # We can go over command line length here, so be careful.
 quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
-      cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | $(modpost) $(MODPOST_OPT) -s -T -
+      cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/$(modpost-ext)\.o/' | $(modpost) $(MODPOST_OPT) -s -T -
 
 PHONY += __modpost
-__modpost: $(modules:.ko=.o) FORCE
+__modpost: $(modules:.ko=$(modpost-ext).o) FORCE
 	$(call cmd,modpost) $(wildcard vmlinux)
 
 quiet_cmd_kernel-mod = MODPOST $@
@@ -98,8 +132,7 @@ vmlinux.o: FORCE
 	$(call cmd,kernel-mod)
 
 # Declare generated files as targets for modpost
-$(modules:.ko=.mod.c): __modpost ;
-
+$(modules:.ko=$(modpost-ext).mod.c): __modpost ;
 
 # Step 5), compile all *.mod.c files
 
@@ -110,23 +143,37 @@ quiet_cmd_cc_o_c = CC      $@
       cmd_cc_o_c = $(CC) $(c_flags) $(KBUILD_CFLAGS_MODULE) $(CFLAGS_MODULE) \
 		   -c -o $@ $<
 
-$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
+$(modules:.ko=.mod.o): %.mod.o: %$(modpost-ext).mod.c FORCE
 	$(call if_changed_dep,cc_o_c)
 
-targets += $(modules:.ko=.mod.o)
+targets += $(modules:.ko=$(modpost-ext).mod.o)
 
 ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
 
 # Step 6), final link of the modules with optional arch pass after final link
 quiet_cmd_ld_ko_o = LD [M]  $@
+
+ifdef CONFIG_CLANG_LTO
+lto_ko_objects = $(foreach o,$(1:$(modpost-ext).o=.o),			\
+			$(shell [ -f $(o).objects ] && 			\
+				 cat $(o).objects || echo $(o)))
+
+      cmd_ld_ko_o = 							\
+	$(LD) -r $(LDFLAGS)                                 		\
+		 $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) 		\
+		 $(shell [ -s $(@:.ko=.modversions) ] &&		\
+			echo -T $(@:.ko=.modversions))  		\
+		 -o $@ $(call lto_ko_objects, $(filter-out FORCE,$^))
+else
       cmd_ld_ko_o =                                                     \
 	$(LD) -r $(LDFLAGS)                                             \
                  $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE)             \
                  -o $@ $(filter-out FORCE,$^) ;                         \
 	$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
+endif
 
-$(modules): %.ko :%.o %.mod.o FORCE
-	+$(call if_changed,ld_ko_o)
+$(modules): %.ko: %$(modpost-ext).o %.mod.o FORCE
+	$(call if_changed,ld_ko_o)
 
 targets += $(modules)
 
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index e6818b8e7141..c5c004b209ce 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -64,6 +64,53 @@ archive_builtin()
 	fi
 }
 
+# If CONFIG_CLANG_LTO is selected, the compiler produces LLVM IR files instead
+# of ELF object files. This function expands individual IR files from a list of
+# objects that would have otherwise been linked already.
+expand()
+{
+	if [ -z "${CONFIG_CLANG_LTO}" ]; then
+		echo $*
+	fi
+
+	local objs
+
+	for o in $*; do
+		if [ -f ${o}.objects ]; then
+			objs="${objs} $(xargs < ${o}.objects)"
+		else
+			objs="${objs} ${o}"
+		fi
+	done
+
+	echo "${objs}"
+}
+
+# If CONFIG_CLANG_LTO is selected, collect generated symbol versions into
+# .tmp_symversions
+modversions()
+{
+	if [ -z "${CONFIG_CLANG_LTO}" ]; then
+		return
+	fi
+
+	if [ -z "${CONFIG_MODVERSIONS}" ]; then
+		return
+	fi
+
+	rm -f .tmp_symversions
+
+	for o in $(expand ${KBUILD_VMLINUX_INIT}) \
+		 $(expand ${KBUILD_VMLINUX_MAIN}) \
+		 $(expand ${KBUILD_VMLINUX_LIBS}); do
+		if [ -f ${o}.symversions ]; then
+			cat ${o}.symversions >> .tmp_symversions
+		fi
+	done
+
+	echo "-T .tmp_symversions"
+}
+
 # Link of vmlinux.o used for section mismatch analysis
 # ${1} output file
 modpost_link()
@@ -78,13 +125,22 @@ modpost_link()
 			${KBUILD_VMLINUX_LIBS}				\
 			--end-group"
 	else
-		objects="${KBUILD_VMLINUX_INIT}				\
+		objects="$(expand ${KBUILD_VMLINUX_INIT})		\
 			--start-group					\
-			${KBUILD_VMLINUX_MAIN}				\
-			${KBUILD_VMLINUX_LIBS}				\
+			$(expand ${KBUILD_VMLINUX_MAIN})		\
+			$(expand ${KBUILD_VMLINUX_LIBS})		\
 			--end-group"
 	fi
-	${LD} ${LDFLAGS} -r -o ${1} ${objects}
+
+	if [ -n "${CONFIG_CLANG_LTO}" ]; then
+		# This might take a while, so indicate that we're doing
+		# an LTO link
+		info LTO vmlinux.o
+	else
+		info LD vmlinux.o
+	fi
+
+	${LD} ${LDFLAGS} -r -o ${1} $(modversions) ${objects}
 }
 
 # Link of vmlinux
@@ -96,6 +152,14 @@ vmlinux_link()
 	local objects
 
 	if [ "${SRCARCH}" != "um" ]; then
+		local ld=${LD}
+		local ldflags="${LDFLAGS} ${LDFLAGS_vmlinux}"
+
+		if [ -n "${LD_FINAL_VMLINUX}" ]; then
+			ld=${LD_FINAL_VMLINUX}
+			ldflags="${LDFLAGS_FINAL_VMLINUX} ${LDFLAGS_vmlinux}"
+		fi
+
 		if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
 			objects="--whole-archive			\
 				built-in.o				\
@@ -105,16 +169,15 @@ vmlinux_link()
 				--end-group				\
 				${1}"
 		else
-			objects="${KBUILD_VMLINUX_INIT}			\
+			objects="$(expand ${KBUILD_VMLINUX_INIT})	\
 				--start-group				\
-				${KBUILD_VMLINUX_MAIN}			\
-				${KBUILD_VMLINUX_LIBS}			\
+				$(expand ${KBUILD_VMLINUX_MAIN})	\
+				$(expand ${KBUILD_VMLINUX_LIBS})	\
 				--end-group				\
 				${1}"
 		fi
 
-		${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2}		\
-			-T ${lds} ${objects}
+		${ld} ${ldflags} -o ${2} -T ${lds} ${objects}
 	else
 		if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
 			objects="-Wl,--whole-archive			\
@@ -141,7 +204,6 @@ vmlinux_link()
 	fi
 }
 
-
 # Create ${2} .o file with all symbols from the ${1} object file
 kallsyms()
 {
@@ -192,6 +254,7 @@ cleanup()
 	rm -f .tmp_System.map
 	rm -f .tmp_kallsyms*
 	rm -f .tmp_version
+	rm -f .tmp_symversions
 	rm -f .tmp_vmlinux*
 	rm -f built-in.o
 	rm -f System.map
@@ -253,12 +316,19 @@ ${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init GCC_PLUGINS_CFLAGS="${GC
 archive_builtin
 
 #link vmlinux.o
-info LD vmlinux.o
 modpost_link vmlinux.o
 
 # modpost vmlinux.o to check for section mismatches
 ${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
 
+if [ -n "${CONFIG_CLANG_LTO}" ]; then
+	# Re-use vmlinux.o, so we can avoid the slow LTO link step in
+	# vmlinux_link
+	KBUILD_VMLINUX_INIT=
+	KBUILD_VMLINUX_MAIN=vmlinux.o
+	KBUILD_VMLINUX_LIBS=
+fi
+
 kallsymso=""
 kallsyms_vmlinux=""
 if [ -n "${CONFIG_KALLSYMS}" ]; then
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 04/15] kbuild: fix dynamic ftrace with clang LTO

[Sami Tolvanen]

With CONFIG_CLANG_LTO enabled, LLVM IR won't be compiled into object
files until modpost_link. This change postpones calls to recordmcount
until after this step.

In order to exclude ftrace_process_locs from inspection, we add a new
code section .text..ftrace, which we tell recordmcount to ignore, and
a __norecordmcount attribute for moving functions to this section.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/Kconfig                      |  2 +-
 include/asm-generic/vmlinux.lds.h |  2 +-
 include/linux/compiler-clang.h    |  7 +++++++
 include/linux/compiler.h          |  4 ++++
 kernel/trace/ftrace.c             |  6 +++---
 scripts/Makefile.build            | 14 +++++++++++++-
 scripts/Makefile.modpost          |  4 ++++
 scripts/link-vmlinux.sh           | 16 ++++++++++++++++
 scripts/recordmcount.c            |  3 ++-
 9 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 6b0c9d4de369..b82276a64045 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -617,7 +617,7 @@ config ARCH_SUPPORTS_CLANG_LTO
 config CLANG_LTO
 	bool "Use clang Link Time Optimization (LTO)"
 	depends on ARCH_SUPPORTS_CLANG_LTO
-	depends on !FTRACE_MCOUNT_RECORD
+	depends on !FTRACE_MCOUNT_RECORD || HAVE_C_RECORDMCOUNT
 	select LD_DEAD_CODE_DATA_ELIMINATION
 	help
           This option enables clang's Link Time Optimization (LTO), which allows
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d0070985c191..99e794b8eec7 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -458,7 +458,7 @@
  */
 #define TEXT_TEXT							\
 		ALIGN_FUNCTION();					\
-		*(.text.hot TEXT_MAIN .text.fixup .text.unlikely)	\
+		*(.text.hot TEXT_MAIN .text.fixup .text.unlikely .text..ftrace)	\
 		*(.ref.text)						\
 	MEM_KEEP(init.text)						\
 	MEM_KEEP(exit.text)						\
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 54dfef70a072..0f9fe03e5364 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -16,3 +16,10 @@
  * with any version that can compile the kernel
  */
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#ifdef CONFIG_CLANG_LTO
+#ifdef CONFIG_FTRACE_MCOUNT_RECORD
+#define __norecordmcount \
+	__attribute__((__section__(".text..ftrace")))
+#endif
+#endif
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index fd8697aa4f73..94fe175a06e9 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -502,6 +502,10 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
 #define __visible
 #endif
 
+#ifndef __norecordmcount
+#define __norecordmcount
+#endif
+
 #ifndef __nostackprotector
 # define __nostackprotector
 #endif
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 8319e09e15b9..e117b849f9dc 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5573,9 +5573,9 @@ static int ftrace_cmp_ips(const void *a, const void *b)
 	return 0;
 }
 
-static int ftrace_process_locs(struct module *mod,
-			       unsigned long *start,
-			       unsigned long *end)
+static int __norecordmcount ftrace_process_locs(struct module *mod,
+						unsigned long *start,
+						unsigned long *end)
 {
 	struct ftrace_page *start_pg;
 	struct ftrace_page *pg;
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 0cff240454f8..e69a02dec7bb 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -246,6 +246,12 @@ ifdef BUILD_C_RECORDMCOUNT
 ifeq ("$(origin RECORDMCOUNT_WARN)", "command line")
   RECORDMCOUNT_FLAGS = -w
 endif
+
+ifdef CONFIG_CLANG_LTO
+# With LTO, we postpone running recordmcount until after the LTO link step, so
+# let's export the parameters for the link script.
+export RECORDMCOUNT_FLAGS
+else
 # Due to recursion, we must skip empty.o.
 # The empty.o file is created in the make process in order to determine
 # the target endianness and word size. It is made before all other C
@@ -254,17 +260,22 @@ sub_cmd_record_mcount =					\
 	if [ $(@) != "scripts/mod/empty.o" ]; then	\
 		$(objtree)/scripts/recordmcount $(RECORDMCOUNT_FLAGS) "$(@)";	\
 	fi;
+endif
+
 recordmcount_source := $(srctree)/scripts/recordmcount.c \
 		    $(srctree)/scripts/recordmcount.h
-else
+else # !BUILD_C_RECORDMCOUNT
 sub_cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
 	"$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)" \
 	"$(if $(CONFIG_64BIT),64,32)" \
 	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC) $(KBUILD_CFLAGS)" \
 	"$(LD)" "$(NM)" "$(RM)" "$(MV)" \
 	"$(if $(part-of-module),1,0)" "$(@)";
+
 recordmcount_source := $(srctree)/scripts/recordmcount.pl
 endif # BUILD_C_RECORDMCOUNT
+
+ifndef CONFIG_CLANG_LTO
 cmd_record_mcount =						\
 	if [ "$(findstring $(CC_FLAGS_FTRACE),$(_c_flags))" =	\
 	     "$(CC_FLAGS_FTRACE)" ]; then			\
@@ -287,6 +298,7 @@ objtool_args += --no-unreachable
 else
 objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable)
 endif
+endif # CONFIG_FTRACE_MCOUNT_RECORD
 
 # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory
 # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 2f3b45cbbe6b..da0c975ac4ed 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -164,6 +164,10 @@ lto_ko_objects = $(foreach o,$(1:$(modpost-ext).o=.o),			\
 		 $(shell [ -s $(@:.ko=.modversions) ] &&		\
 			echo -T $(@:.ko=.modversions))  		\
 		 -o $@ $(call lto_ko_objects, $(filter-out FORCE,$^))
+
+ifdef CONFIG_FTRACE_MCOUNT_RECORD
+cmd_ld_ko_o += ; $(objtree)/scripts/recordmcount $(RECORDMCOUNT_FLAGS) $@
+endif
 else
       cmd_ld_ko_o =                                                     \
 	$(LD) -r $(LDFLAGS)                                             \
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c5c004b209ce..76e1da946f08 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -143,6 +143,19 @@ modpost_link()
 	${LD} ${LDFLAGS} -r -o ${1} $(modversions) ${objects}
 }
 
+# If CONFIG_CLANG_LTO is selected, we postpone running recordmcount until
+# we have compiled LLVM IR to an object file.
+recordmcount()
+{
+	if [ -z "${CONFIG_CLANG_LTO}" ]; then
+		return
+	fi
+
+	if [ -n "${CONFIG_FTRACE_MCOUNT_RECORD}" ]; then
+		scripts/recordmcount ${RECORDMCOUNT_FLAGS} $*
+	fi
+}
+
 # Link of vmlinux
 # ${1} - optional extra .o files
 # ${2} - output file
@@ -327,6 +340,9 @@ if [ -n "${CONFIG_CLANG_LTO}" ]; then
 	KBUILD_VMLINUX_INIT=
 	KBUILD_VMLINUX_MAIN=vmlinux.o
 	KBUILD_VMLINUX_LIBS=
+
+	# Call recordmcount if needed
+	recordmcount vmlinux.o
 fi
 
 kallsymso=""
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index 16e086dcc567..69a769904da7 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -420,7 +420,8 @@ is_mcounted_section_name(char const *const txtname)
 		strcmp(".softirqentry.text", txtname) == 0 ||
 		strcmp(".kprobes.text", txtname) == 0 ||
 		strcmp(".cpuidle.text", txtname) == 0 ||
-		strcmp(".text.unlikely", txtname) == 0;
+		(strncmp(".text.",       txtname, 6) == 0 &&
+		 strcmp(".text..ftrace", txtname) != 0);
 }
 
 /* 32 bit and 64 bit are very similar */
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 05/15] scripts/mod: disable LTO for empty.c

[Sami Tolvanen]

With CONFIG_CLANG_LTO, clang generates LLVM IR instead of ELF object
files. As empty.o is used for probing target properties, disable LTO
for it to produce an object file instead.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 scripts/mod/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile
index 42c5d50f2bcc..e014b2fdd069 100644
--- a/scripts/mod/Makefile
+++ b/scripts/mod/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 OBJECT_FILES_NON_STANDARD := y
+CFLAGS_empty.o += $(DISABLE_LTO)
 
 hostprogs-y	:= modpost mk_elfconfig
 always		:= $(hostprogs-y) empty.o
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 06/15] efi/libstub: disable clang LTO

[Sami Tolvanen]

With CONFIG_CLANG_LTO, we produce LLVM IR instead of object files. Since LTO
is not really needed here and the Makefile assumes we produce an object file,
disable LTO for libstub.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/efi/libstub/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 2371a92808be..5146eee677ce 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB)	+= -I$(srctree)/scripts/dtc/libfdt
 KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
 				   -D__NO_FORTIFY \
 				   $(call cc-option,-ffreestanding) \
-				   $(call cc-option,-fno-stack-protector)
+				   $(call cc-option,-fno-stack-protector) \
+				   $(DISABLE_LTO)
 
 GCOV_PROFILE			:= n
 KASAN_SANITIZE			:= n
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 06/15] efi/libstub: disable clang LTO

[Ard Biesheuvel]

On 3 November 2017 at 17:11, Sami Tolvanen <samitolvanen@google.com> wrote:
> With CONFIG_CLANG_LTO, we produce LLVM IR instead of object files. Since LTO
> is not really needed here and the Makefile assumes we produce an object file,
> disable LTO for libstub.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  drivers/firmware/efi/libstub/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index 2371a92808be..5146eee677ce 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB)  += -I$(srctree)/scripts/dtc/libfdt
>  KBUILD_CFLAGS                  := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>                                    -D__NO_FORTIFY \
>                                    $(call cc-option,-ffreestanding) \
> -                                  $(call cc-option,-fno-stack-protector)
> +                                  $(call cc-option,-fno-stack-protector) \
> +                                  $(DISABLE_LTO)
>
>  GCOV_PROFILE                   := n
>  KASAN_SANITIZE                 := n
> --
> 2.15.0.403.gc27cc4dac6-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 06/15] efi/libstub: disable LTO

[Sami Tolvanen]

With CONFIG_CLANG_LTO, we produce LLVM IR instead of object files. Since LTO
is not really needed here and the Makefile assumes we produce an object file,
disable LTO for libstub.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/efi/libstub/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 2371a92808be..5146eee677ce 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB)	+= -I$(srctree)/scripts/dtc/libfdt
 KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
 				   -D__NO_FORTIFY \
 				   $(call cc-option,-ffreestanding) \
-				   $(call cc-option,-fno-stack-protector)
+				   $(call cc-option,-fno-stack-protector) \
+				   $(DISABLE_LTO)
 
 GCOV_PROFILE			:= n
 KASAN_SANITIZE			:= n
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Sami Tolvanen]

From: Greg Hackmann <ghackmann@google.com>

LLVM bug 30792 causes clang's AArch64 backend to crash compiling
arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
-mno-implicit-float is the suggested workaround.

Signed-off-by: Greg Hackmann <ghackmann@google.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 939b310913cf..eb6f3c9ec6cb 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -45,7 +45,13 @@ $(warning Detected assembler with broken .inst; disassembly will be unreliable)
   endif
 endif
 
-KBUILD_CFLAGS	+= -mgeneral-regs-only $(lseinstr) $(brokengasinst)
+ifeq ($(cc-name),clang)
+# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792.
+KBUILD_CFLAGS	+= -mno-implicit-float
+else
+KBUILD_CFLAGS	+= -mgeneral-regs-only
+endif
+KBUILD_CFLAGS	+= $(lseinstr) $(brokengasinst)
 KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
 KBUILD_CFLAGS	+= $(call cc-option, -mpc-relative-literal-loads)
 KBUILD_AFLAGS	+= $(lseinstr) $(brokengasinst)
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Nick Desaulniers]

I think this bug was fixed upstream in LLVM.  Do we still want to take
this workaround?

On Fri, Nov 3, 2017 at 10:11 AM, Sami Tolvanen <samitolvanen@google.com> wrote:
> From: Greg Hackmann <ghackmann@google.com>
>
> LLVM bug 30792 causes clang's AArch64 backend to crash compiling
> arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
> -mno-implicit-float is the suggested workaround.
>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Cc: Matthias Kaehlcke <mka@chromium.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 939b310913cf..eb6f3c9ec6cb 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -45,7 +45,13 @@ $(warning Detected assembler with broken .inst; disassembly will be unreliable)
>    endif
>  endif
>
> -KBUILD_CFLAGS  += -mgeneral-regs-only $(lseinstr) $(brokengasinst)
> +ifeq ($(cc-name),clang)
> +# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792.
> +KBUILD_CFLAGS  += -mno-implicit-float
> +else
> +KBUILD_CFLAGS  += -mgeneral-regs-only
> +endif
> +KBUILD_CFLAGS  += $(lseinstr) $(brokengasinst)
>  KBUILD_CFLAGS  += -fno-asynchronous-unwind-tables
>  KBUILD_CFLAGS  += $(call cc-option, -mpc-relative-literal-loads)
>  KBUILD_AFLAGS  += $(lseinstr) $(brokengasinst)
> --
> 2.15.0.403.gc27cc4dac6-goog
>



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Mark Rutland]

On Fri, Nov 03, 2017 at 10:11:52AM -0700, Sami Tolvanen wrote:
> From: Greg Hackmann <ghackmann@google.com>
> 
> LLVM bug 30792 causes clang's AArch64 backend to crash compiling
> arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
> -mno-implicit-float is the suggested workaround.
> 
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Cc: Matthias Kaehlcke <mka@chromium.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Ah, so I guess this is what I was hitting when testing with clang 5.0.0.

I was under the impression that this series was jsut enablnig LTO
support, not clang support generally.

It would be much nicer if we could depend on a fixed clang to start
with...

Thanks,
Mark.

> ---
>  arch/arm64/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 939b310913cf..eb6f3c9ec6cb 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -45,7 +45,13 @@ $(warning Detected assembler with broken .inst; disassembly will be unreliable)
>    endif
>  endif
>  
> -KBUILD_CFLAGS	+= -mgeneral-regs-only $(lseinstr) $(brokengasinst)
> +ifeq ($(cc-name),clang)
> +# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792.
> +KBUILD_CFLAGS	+= -mno-implicit-float
> +else
> +KBUILD_CFLAGS	+= -mgeneral-regs-only
> +endif
> +KBUILD_CFLAGS	+= $(lseinstr) $(brokengasinst)
>  KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
>  KBUILD_CFLAGS	+= $(call cc-option, -mpc-relative-literal-loads)
>  KBUILD_AFLAGS	+= $(lseinstr) $(brokengasinst)
> -- 
> 2.15.0.403.gc27cc4dac6-goog
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Nick Desaulniers]

On Fri, Nov 3, 2017 at 11:02 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Ah, so I guess this is what I was hitting when testing with clang 5.0.0.

Exactly.

> I was under the impression that this series was jsut enablnig LTO
> support, not clang support generally.

Clang is supported at least for the arm64*/x86-64 configs that we've
gotten around to testing.

* minus this one last compiler bug (but maybe "last" is optimistic).

> It would be much nicer if we could depend on a fixed clang to start
> with...

I agree, which is why I'm on the fence with this patch.  With a newer
version of Clang, it's not needed.

There are some kbuild macros for certain versions of GCC, maybe
something like that can be used to conditionally swap these flags if
using an older version of Clang?

>> +# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792.
>> +KBUILD_CFLAGS        += -mno-implicit-float
>> +else
>> +KBUILD_CFLAGS        += -mgeneral-regs-only
>> +endif

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Mark Rutland]

On Fri, Nov 03, 2017 at 10:11:52AM -0700, Sami Tolvanen wrote:
> From: Greg Hackmann <ghackmann@google.com>
> 
> LLVM bug 30792 causes clang's AArch64 backend to crash compiling
> arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
> -mno-implicit-float is the suggested workaround.
> 
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Cc: Matthias Kaehlcke <mka@chromium.org>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Just to check, what happens if you pass both to clang?

If it works when you pass both...

> -KBUILD_CFLAGS	+= -mgeneral-regs-only $(lseinstr) $(brokengasinst)
> +ifeq ($(cc-name),clang)
> +# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792.
> +KBUILD_CFLAGS	+= -mno-implicit-float
> +else
> +KBUILD_CFLAGS	+= -mgeneral-regs-only
> +endif

... then this can be reduced to:

# This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=30792
KBUILD_CFLAGS		+= $(call cc-option, -mno-implicit-float)

Thanks,
Mark.

> +KBUILD_CFLAGS	+= $(lseinstr) $(brokengasinst)
>  KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables
>  KBUILD_CFLAGS	+= $(call cc-option, -mpc-relative-literal-loads)
>  KBUILD_AFLAGS	+= $(lseinstr) $(brokengasinst)
> -- 
> 2.15.0.403.gc27cc4dac6-goog
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Mark Rutland]

On Fri, Nov 03, 2017 at 06:31:56PM +0000, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 10:11:52AM -0700, Sami Tolvanen wrote:
> > From: Greg Hackmann <ghackmann@google.com>
> > 
> > LLVM bug 30792 causes clang's AArch64 backend to crash compiling
> > arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
> > -mno-implicit-float is the suggested workaround.
> > 
> > Signed-off-by: Greg Hackmann <ghackmann@google.com>
> > Cc: Matthias Kaehlcke <mka@chromium.org>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> 
> Just to check, what happens if you pass both to clang?

Apparently not. However, we can do:

-KBUILD_CFLAGS  += -mgeneral-regs-only $(lseinstr) $(brokengasinst)
+KBUILD_CFLAGS  += $(lseinstr) $(brokengasinst)
+# Clang workaround for https://bugs.llvm.org/show_bug.cgi?id=30792
+KBUILD_CFLAGS  += $(call cc-option, -mno-implicit-float, -mgeneral-regs-only)

Thanks,
Mark.

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Kees Cook]

On Fri, Nov 3, 2017 at 11:52 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 03, 2017 at 06:31:56PM +0000, Mark Rutland wrote:
>> On Fri, Nov 03, 2017 at 10:11:52AM -0700, Sami Tolvanen wrote:
>> > From: Greg Hackmann <ghackmann@google.com>
>> >
>> > LLVM bug 30792 causes clang's AArch64 backend to crash compiling
>> > arch/arm64/crypto/aes-ce-cipher.c.  Replacing -mgeneral-regs-only with
>> > -mno-implicit-float is the suggested workaround.
>> >
>> > Signed-off-by: Greg Hackmann <ghackmann@google.com>
>> > Cc: Matthias Kaehlcke <mka@chromium.org>
>> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>>
>> Just to check, what happens if you pass both to clang?
>
> Apparently not. However, we can do:
>
> -KBUILD_CFLAGS  += -mgeneral-regs-only $(lseinstr) $(brokengasinst)
> +KBUILD_CFLAGS  += $(lseinstr) $(brokengasinst)
> +# Clang workaround for https://bugs.llvm.org/show_bug.cgi?id=30792
> +KBUILD_CFLAGS  += $(call cc-option, -mno-implicit-float, -mgeneral-regs-only)

Should a clang version test be included, since we know at least 5.0 is
need (with this fix)? There are distros with much earlier versions of
clang, for example...

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 07/15] arm64: use -mno-implicit-float instead of -mgeneral-regs-only

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 12:06:15PM -0700, Kees Cook wrote:
> Should a clang version test be included, since we know at least 5.0 is
> need (with this fix)? There are distros with much earlier versions of
> clang, for example...

Greg knows better, but I remember him mentioning that upstream clang
doesn't generate any worse code with -mno-implicit-float, so there should
be no harm in using this workaround with all versions.

This might change in future, of course, so I don't have objections to
adding a check for clang version < 6.0 here.

Sami

[PATCH 08/15] arm64: don't pass -maarch64linux to GNU gold

[Sami Tolvanen]

This change fixes the following error message when linking with GNU
gold:

  ld.gold: error: unrecognized emulation aarch64linux

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index eb6f3c9ec6cb..c16bd1ab37f8 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -64,14 +64,18 @@ KBUILD_CPPFLAGS	+= -mbig-endian
 CHECKFLAGS	+= -D__AARCH64EB__
 AS		+= -EB
 LD		+= -EB
+ifneq ($(ld-name),gold)
 LDFLAGS		+= -maarch64linuxb
+endif
 UTS_MACHINE	:= aarch64_be
 else
 KBUILD_CPPFLAGS	+= -mlittle-endian
 CHECKFLAGS	+= -D__AARCH64EL__
 AS		+= -EL
 LD		+= -EL
+ifneq ($(ld-name),gold)
 LDFLAGS		+= -maarch64linux
+endif
 UTS_MACHINE	:= aarch64
 endif
 
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 08/15] arm64: don't pass -maarch64linux to GNU gold

[Yury Norov]

Hi Sami,

Very interesting reading, thank you.

On Fri, Nov 03, 2017 at 10:11:53AM -0700, Sami Tolvanen wrote:
> This change fixes the following error message when linking with GNU
> gold:
> 
>   ld.gold: error: unrecognized emulation aarch64linux
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/Makefile | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index eb6f3c9ec6cb..c16bd1ab37f8 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -64,14 +64,18 @@ KBUILD_CPPFLAGS	+= -mbig-endian
>  CHECKFLAGS	+= -D__AARCH64EB__
>  AS		+= -EB
>  LD		+= -EB
> +ifneq ($(ld-name),gold)
>  LDFLAGS		+= -maarch64linuxb
> +endif
>  UTS_MACHINE	:= aarch64_be
>  else
>  KBUILD_CPPFLAGS	+= -mlittle-endian
>  CHECKFLAGS	+= -D__AARCH64EL__
>  AS		+= -EL
>  LD		+= -EL
> +ifneq ($(ld-name),gold)
>  LDFLAGS		+= -maarch64linux
> +endif
>  UTS_MACHINE	:= aarch64
>  endif

-maarch64linux was added to LDFLAGS, and -mabi=lp64 was added to CFLAGS
at the same patch to ensure that kernel will be compiled and linked in
lp64 mode, even if toolchain by default compiles and links targets in
ilp32 mode. So I think that simple removing this flag looks inaccurate.

Also, IIUC, this patch is not related to LTO, because if ld.gold doesn't
recognize -maarch64linux with LTO, it will not recognize it in non-LTO
build. Am I right?

I think that more correct way to do it would be either:
 - add maarch64linux to ld.gold, if possible. In discussion to other
   patches people talk that they need very fresh clang to build kernel
   properly, so this may be considered as similar issue;
 - if ld.gold understands some synonyms like -mabi=lp64, it should be
   passed to LDFLAGS here;
 - if ld.gold can link only lp64 objects, it should be commented here.
   But in this case I don't understand for example how to build vdso
   for ilp32 userspace...

Thanks,
Yury

Re: [PATCH 08/15] arm64: don't pass -maarch64linux to GNU gold

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 11:41:57PM +0300, Yury Norov wrote:
> Also, IIUC, this patch is not related to LTO, because if ld.gold doesn't
> recognize -maarch64linux with LTO, it will not recognize it in non-LTO
> build. Am I right?

That's correct. ld.gold --help says -m is obsolete, but at the same time,
it supports a number of emulations, just with different names than ld.bfd.
I'll take a closer look at this and see if there's a different flag we
should be passing here instead. Looks like I also have some 0-day issues
to address for v2.

Sami

[PATCH 09/15] arm64: keep .altinstructions and .altinstr_replacement

[Sami Tolvanen]

Make sure the linker doesn't remove .altinstructions or
.altinstr_replacement when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is
enabled.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/kernel/vmlinux.lds.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7da3e5c366a0..15479995869c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -138,11 +138,11 @@ SECTIONS
 	. = ALIGN(4);
 	.altinstructions : {
 		__alt_instructions = .;
-		*(.altinstructions)
+		KEEP(*(.altinstructions))
 		__alt_instructions_end = .;
 	}
 	.altinstr_replacement : {
-		*(.altinstr_replacement)
+		KEEP(*(.altinstr_replacement))
 	}
 
 	. = ALIGN(PAGE_SIZE);
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 09/15] arm64: keep .altinstructions and .altinstr_replacement

[Nick Desaulniers]

This patch can likely be taken regardless of the rest of the series.
It would be good to get additional review from the person who added
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION maybe?

On Fri, Nov 3, 2017 at 10:11 AM, Sami Tolvanen <samitolvanen@google.com> wrote:
> Make sure the linker doesn't remove .altinstructions or
> .altinstr_replacement when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is
> enabled.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/kernel/vmlinux.lds.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 7da3e5c366a0..15479995869c 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -138,11 +138,11 @@ SECTIONS
>         . = ALIGN(4);
>         .altinstructions : {
>                 __alt_instructions = .;
> -               *(.altinstructions)
> +               KEEP(*(.altinstructions))
>                 __alt_instructions_end = .;
>         }
>         .altinstr_replacement : {
> -               *(.altinstr_replacement)
> +               KEEP(*(.altinstr_replacement))
>         }
>
>         . = ALIGN(PAGE_SIZE);
> --
> 2.15.0.403.gc27cc4dac6-goog
>



-- 
Thanks,
~Nick Desaulniers

[PATCH 10/15] arm64: disable ARM64_ERRATUM_843419 for clang LTO

[Sami Tolvanen]

CONFIG_CLANG_LTO depends on GNU gold, which can generate ADR_PREL_PG_HI21
relocations even with --fix-cortex-a53-843419.

Since ARM64_ERRATUM_843419 disables kernel support for these relocations,
disable the erratum when LTO is used.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6a56d4..43ccddb7c8ec 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -433,6 +433,7 @@ config ARM64_ERRATUM_845719
 
 config ARM64_ERRATUM_843419
 	bool "Cortex-A53: 843419: A load or store might access an incorrect address"
+	depends on !CLANG_LTO
 	default y
 	select ARM64_MODULE_CMODEL_LARGE if MODULES
 	help
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 10/15] arm64: disable ARM64_ERRATUM_843419 for clang LTO

[Ard Biesheuvel]

On 3 November 2017 at 17:11, Sami Tolvanen <samitolvanen@google.com> wrote:
> CONFIG_CLANG_LTO depends on GNU gold, which can generate ADR_PREL_PG_HI21
> relocations even with --fix-cortex-a53-843419.
>
> Since ARM64_ERRATUM_843419 disables kernel support for these relocations,
> disable the erratum when LTO is used.
>

I wonder it makes sense to disable such relocations entirely when we
enable this erratum. If the toolchain does not generate them, they
shouldn't occur in the first place, and having this dependency here
seems awkward as well.

> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 0df64a6a56d4..43ccddb7c8ec 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -433,6 +433,7 @@ config ARM64_ERRATUM_845719
>
>  config ARM64_ERRATUM_843419
>         bool "Cortex-A53: 843419: A load or store might access an incorrect address"
> +       depends on !CLANG_LTO
>         default y
>         select ARM64_MODULE_CMODEL_LARGE if MODULES
>         help
> --
> 2.15.0.403.gc27cc4dac6-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 10/15] arm64: disable ARM64_ERRATUM_843419 for clang LTO

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 08:13:20PM +0000, Ard Biesheuvel wrote:
> I wonder it makes sense to disable such relocations entirely when we
> enable this erratum. If the toolchain does not generate them, they
> shouldn't occur in the first place, and having this dependency here
> seems awkward as well.

I agree. Unless someone objects, I'll replace this in v2 with a patch that
leaves the relocations in module.c even when the erratum is selected.

Sami

[PATCH 11/15] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

[Sami Tolvanen]

Some versions of GNU gold are known to produce broken code with
--fix-cortex-a53-843419 as explained in this bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21491

If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass
--no-fix-cortex-a53-843419 to the linker to ensure the erratum fix is not
used even if the linker is configured to enable it by default.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index c16bd1ab37f8..0c1fb297c98e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -26,6 +26,11 @@ LDFLAGS_vmlinux	+= --fix-cortex-a53-843419
   endif
 endif
 
+ifeq ($(CONFIG_ARM64_ERRATUM_843419),)
+# https://sourceware.org/bugzilla/show_bug.cgi?id=21491
+LDFLAGS_GOLD	+= --no-fix-cortex-a53-843419
+endif
+
 KBUILD_DEFCONFIG := defconfig
 
 # Check for binutils support for specific extensions
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 11/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Sami Tolvanen]

Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:

  https://bugs.llvm.org/show_bug.cgi?id=19749

As binutils doesn't allow macros to be redefined, this change adds C
preprocessor macros that define the assembly macros globally for binutils
and locally for clang's integrated assembler.

Suggested-by: Greg Hackmann <ghackmann@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/kvm_hyp.h |  2 ++
 arch/arm64/include/asm/sysreg.h  | 71 ++++++++++++++++++++++++++++++----------
 2 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 4572a9b560fa..6840704ea894 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -29,6 +29,7 @@
 	({								\
 		u64 reg;						\
 		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
+					 DEFINE_MRS_S			\
 					 "mrs_s %0, " __stringify(r##vh),\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 			     : "=r" (reg));				\
@@ -39,6 +40,7 @@
 	do {								\
 		u64 __val = (u64)(v);					\
 		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
+					 DEFINE_MSR_S			\
 					 "msr_s " __stringify(r##vh) ", %x0",\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 					 : : "rZ" (__val));		\
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f707fed5886f..1588ac3f3690 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -463,21 +463,58 @@
 
 #include <linux/types.h>
 
-asm(
-"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
-"	.equ	.L__reg_num_x\\num, \\num\n"
-"	.endr\n"
+#define ___MRS_MSR_S_REGNUM					\
+"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n" \
+"	.equ	.L__reg_num_x\\num, \\num\n"			\
+"	.endr\n"						\
 "	.equ	.L__reg_num_xzr, 31\n"
-"\n"
-"	.macro	mrs_s, rt, sreg\n"
-	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define ___MRS_S						\
+"	.macro	mrs_s, rt, sreg\n"				\
+	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
-"\n"
-"	.macro	msr_s, sreg, rt\n"
-	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define ___MSR_S						\
+"	.macro	msr_s, sreg, rt\n"				\
+	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
+
+/*
+ * llvm-as doesn't allow macros defined in an asm block to be used in other
+ * asm blocks, which means we cannot define them globally.
+ */
+#if !defined(CONFIG_CLANG_LTO)
+asm(
+	___MRS_MSR_S_REGNUM
+	___MRS_S
+	___MSR_S
 );
 
+#undef  ___MRS_MSR_S_REGNUM
+#define ___MRS_MSR_S_REGNUM
+#undef  ___MRS_S
+#define ___MRS_S
+#undef  ___MSR_S
+#define ___MSR_S
+#endif
+
+#define DEFINE_MRS_S		\
+	___MRS_MSR_S_REGNUM	\
+	___MRS_S
+
+#define DEFINE_MSR_S		\
+	___MRS_MSR_S_REGNUM	\
+	___MSR_S
+
+
+#define __mrs_s(r, v)						\
+	DEFINE_MRS_S						\
+"	mrs_s %0, " __stringify(r) : "=r" (v)
+
+#define __msr_s(r, v)						\
+	DEFINE_MSR_S						\
+"	msr_s " __stringify(r) ", %0" : : "r" (v)
+
 /*
  * Unlike read_cpuid, calls to read_sysreg are never expected to be
  * optimized away or replaced with synthetic values.
@@ -502,15 +539,15 @@ asm(
  * For registers without architectural names, or simply unsupported by
  * GAS.
  */
-#define read_sysreg_s(r) ({						\
-	u64 __val;							\
-	asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val));	\
-	__val;								\
+#define read_sysreg_s(r) ({					\
+	u64 __val;						\
+	asm volatile(__mrs_s(r, __val));			\
+	__val;							\
 })
 
-#define write_sysreg_s(v, r) do {					\
-	u64 __val = (u64)(v);						\
-	asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val));	\
+#define write_sysreg_s(v, r) do {				\
+	u64 __val = (u64)(v);					\
+	asm volatile(__msr_s(r, __val));			\
 } while (0)
 
 static inline void config_sctlr_el1(u32 clear, u32 set)
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 12/15] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

[Sami Tolvanen]

CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the
linker crashes when ARM64_MODULE_PLTS is enabled:

  https://sourceware.org/bugzilla/show_bug.cgi?id=14592

To work around the problem, this change:

  1) Enables ARM64_MODULE_PLTS only when it's needed, i.e. when
     RANDOMIZE_MODULE_REGION_FULL is selected,

  2) and disables RANDOMIZE_MODULE_REGION_FULL with clang LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43ccddb7c8ec..a301fdc90319 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -997,8 +997,8 @@ config RELOCATABLE
 
 config RANDOMIZE_BASE
 	bool "Randomize the address of the kernel image"
-	select ARM64_MODULE_PLTS if MODULES
 	select RELOCATABLE
+	select ARM64_MODULE_PLTS if RANDOMIZE_MODULE_REGION_FULL
 	help
 	  Randomizes the virtual address at which the kernel image is
 	  loaded, as a security feature that deters exploit attempts
@@ -1016,7 +1016,7 @@ config RANDOMIZE_BASE
 
 config RANDOMIZE_MODULE_REGION_FULL
 	bool "Randomize the module region independently from the core kernel"
-	depends on RANDOMIZE_BASE
+	depends on RANDOMIZE_BASE && !CLANG_LTO
 	default y
 	help
 	  Randomizes the location of the module region without considering the
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 12/15] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

[Sami Tolvanen]

Some versions of GNU gold are known to produce broken code with
--fix-cortex-a53-843419 as explained in this bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=21491

If ARM64_ERRATUM_843419 is disabled and we're using GNU gold, pass
--no-fix-cortex-a53-843419 to the linker to ensure the erratum fix is not
used even if the linker is configured to enable it by default.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index c16bd1ab37f8..0c1fb297c98e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -26,6 +26,11 @@ LDFLAGS_vmlinux	+= --fix-cortex-a53-843419
   endif
 endif
 
+ifeq ($(CONFIG_ARM64_ERRATUM_843419),)
+# https://sourceware.org/bugzilla/show_bug.cgi?id=21491
+LDFLAGS_GOLD	+= --no-fix-cortex-a53-843419
+endif
+
 KBUILD_DEFCONFIG := defconfig
 
 # Check for binutils support for specific extensions
-- 
2.15.0.403.gc27cc4dac6-goog

[PATCH 13/15] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

[Sami Tolvanen]

CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the
linker crashes when ARM64_MODULE_PLTS is enabled:

  https://sourceware.org/bugzilla/show_bug.cgi?id=14592

To work around the problem, this change:

  1) Enables ARM64_MODULE_PLTS only when it's needed, i.e. when
     RANDOMIZE_MODULE_REGION_FULL is selected,

  2) and disables RANDOMIZE_MODULE_REGION_FULL with clang LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43ccddb7c8ec..a301fdc90319 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -997,8 +997,8 @@ config RELOCATABLE
 
 config RANDOMIZE_BASE
 	bool "Randomize the address of the kernel image"
-	select ARM64_MODULE_PLTS if MODULES
 	select RELOCATABLE
+	select ARM64_MODULE_PLTS if RANDOMIZE_MODULE_REGION_FULL
 	help
 	  Randomizes the virtual address at which the kernel image is
 	  loaded, as a security feature that deters exploit attempts
@@ -1016,7 +1016,7 @@ config RANDOMIZE_BASE
 
 config RANDOMIZE_MODULE_REGION_FULL
 	bool "Randomize the module region independently from the core kernel"
-	depends on RANDOMIZE_BASE
+	depends on RANDOMIZE_BASE && !CLANG_LTO
 	default y
 	help
 	  Randomizes the location of the module region without considering the
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 13/15] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

[Ard Biesheuvel]

On 3 November 2017 at 17:12, Sami Tolvanen <samitolvanen@google.com> wrote:
> CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the
> linker crashes when ARM64_MODULE_PLTS is enabled:
>
>   https://sourceware.org/bugzilla/show_bug.cgi?id=14592
>
> To work around the problem, this change:
>
>   1) Enables ARM64_MODULE_PLTS only when it's needed, i.e. when
>      RANDOMIZE_MODULE_REGION_FULL is selected,
>

This is not true. Even when RANDOMIZE_MODULE_REGION_FULL is not
enabled, we may need module PLTs.

When the module region is randomized, it shares its chunk of vmalloc
space with other users, and so there is a [low] probability that the
module region we choose is used up by vmalloc/vmap/ioremap
allocations, and so we need to be able to fall back to the general
vmalloc space.

>   2) and disables RANDOMIZE_MODULE_REGION_FULL with clang LTO.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 43ccddb7c8ec..a301fdc90319 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -997,8 +997,8 @@ config RELOCATABLE
>
>  config RANDOMIZE_BASE
>         bool "Randomize the address of the kernel image"
> -       select ARM64_MODULE_PLTS if MODULES
>         select RELOCATABLE
> +       select ARM64_MODULE_PLTS if RANDOMIZE_MODULE_REGION_FULL
>         help
>           Randomizes the virtual address at which the kernel image is
>           loaded, as a security feature that deters exploit attempts
> @@ -1016,7 +1016,7 @@ config RANDOMIZE_BASE
>
>  config RANDOMIZE_MODULE_REGION_FULL
>         bool "Randomize the module region independently from the core kernel"
> -       depends on RANDOMIZE_BASE
> +       depends on RANDOMIZE_BASE && !CLANG_LTO
>         default y
>         help
>           Randomizes the location of the module region without considering the
> --
> 2.15.0.403.gc27cc4dac6-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/15] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 08:09:42PM +0000, Ard Biesheuvel wrote:
> This is not true. Even when RANDOMIZE_MODULE_REGION_FULL is not
> enabled, we may need module PLTs.

Got it. PLTs themselves are not a problem with gold, only the bug when
processing a linker script of this particular format. I'll see if I can
find a better workaround for this for v2.

Sami

[PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Sami Tolvanen]

Clang's integrated assembler does not allow assembly macros defined
in one inline asm block using the .macro directive to be used across
separate asm blocks. LLVM developers consider this a feature and not a
bug, recommending code refactoring:

  https://bugs.llvm.org/show_bug.cgi?id=19749

As binutils doesn't allow macros to be redefined, this change adds C
preprocessor macros that define the assembly macros globally for binutils
and locally for clang's integrated assembler.

Suggested-by: Greg Hackmann <ghackmann@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/kvm_hyp.h |  2 ++
 arch/arm64/include/asm/sysreg.h  | 71 ++++++++++++++++++++++++++++++----------
 2 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 4572a9b560fa..6840704ea894 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -29,6 +29,7 @@
 	({								\
 		u64 reg;						\
 		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
+					 DEFINE_MRS_S			\
 					 "mrs_s %0, " __stringify(r##vh),\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 			     : "=r" (reg));				\
@@ -39,6 +40,7 @@
 	do {								\
 		u64 __val = (u64)(v);					\
 		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
+					 DEFINE_MSR_S			\
 					 "msr_s " __stringify(r##vh) ", %x0",\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 					 : : "rZ" (__val));		\
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f707fed5886f..1588ac3f3690 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -463,21 +463,58 @@
 
 #include <linux/types.h>
 
-asm(
-"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
-"	.equ	.L__reg_num_x\\num, \\num\n"
-"	.endr\n"
+#define ___MRS_MSR_S_REGNUM					\
+"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n" \
+"	.equ	.L__reg_num_x\\num, \\num\n"			\
+"	.endr\n"						\
 "	.equ	.L__reg_num_xzr, 31\n"
-"\n"
-"	.macro	mrs_s, rt, sreg\n"
-	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define ___MRS_S						\
+"	.macro	mrs_s, rt, sreg\n"				\
+	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
-"\n"
-"	.macro	msr_s, sreg, rt\n"
-	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define ___MSR_S						\
+"	.macro	msr_s, sreg, rt\n"				\
+	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
+
+/*
+ * llvm-as doesn't allow macros defined in an asm block to be used in other
+ * asm blocks, which means we cannot define them globally.
+ */
+#if !defined(CONFIG_CLANG_LTO)
+asm(
+	___MRS_MSR_S_REGNUM
+	___MRS_S
+	___MSR_S
 );
 
+#undef  ___MRS_MSR_S_REGNUM
+#define ___MRS_MSR_S_REGNUM
+#undef  ___MRS_S
+#define ___MRS_S
+#undef  ___MSR_S
+#define ___MSR_S
+#endif
+
+#define DEFINE_MRS_S		\
+	___MRS_MSR_S_REGNUM	\
+	___MRS_S
+
+#define DEFINE_MSR_S		\
+	___MRS_MSR_S_REGNUM	\
+	___MSR_S
+
+
+#define __mrs_s(r, v)						\
+	DEFINE_MRS_S						\
+"	mrs_s %0, " __stringify(r) : "=r" (v)
+
+#define __msr_s(r, v)						\
+	DEFINE_MSR_S						\
+"	msr_s " __stringify(r) ", %0" : : "r" (v)
+
 /*
  * Unlike read_cpuid, calls to read_sysreg are never expected to be
  * optimized away or replaced with synthetic values.
@@ -502,15 +539,15 @@ asm(
  * For registers without architectural names, or simply unsupported by
  * GAS.
  */
-#define read_sysreg_s(r) ({						\
-	u64 __val;							\
-	asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val));	\
-	__val;								\
+#define read_sysreg_s(r) ({					\
+	u64 __val;						\
+	asm volatile(__mrs_s(r, __val));			\
+	__val;							\
 })
 
-#define write_sysreg_s(v, r) do {					\
-	u64 __val = (u64)(v);						\
-	asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val));	\
+#define write_sysreg_s(v, r) do {				\
+	u64 __val = (u64)(v);					\
+	asm volatile(__msr_s(r, __val));			\
 } while (0)
 
 static inline void config_sctlr_el1(u32 clear, u32 set)
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Nick Desaulniers]

These mrs_s and msr_s macros in particular were preventing us from
linking arm64 with Clang's integrated assembler, regardless of LTO.
Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
So while I appreciate how clever they are, they prevent us from
assembling with Clang so I would like to see them go.

On Fri, Nov 3, 2017 at 10:12 AM, Sami Tolvanen <samitolvanen@google.com> wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactoring:
>
>   https://bugs.llvm.org/show_bug.cgi?id=19749
>
> As binutils doesn't allow macros to be redefined, this change adds C
> preprocessor macros that define the assembly macros globally for binutils
> and locally for clang's integrated assembler.
>
> Suggested-by: Greg Hackmann <ghackmann@google.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/arm64/include/asm/kvm_hyp.h |  2 ++
>  arch/arm64/include/asm/sysreg.h  | 71 ++++++++++++++++++++++++++++++----------
>  2 files changed, 56 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index 4572a9b560fa..6840704ea894 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -29,6 +29,7 @@
>         ({                                                              \
>                 u64 reg;                                                \
>                 asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
> +                                        DEFINE_MRS_S                   \
>                                          "mrs_s %0, " __stringify(r##vh),\
>                                          ARM64_HAS_VIRT_HOST_EXTN)      \
>                              : "=r" (reg));                             \
> @@ -39,6 +40,7 @@
>         do {                                                            \
>                 u64 __val = (u64)(v);                                   \
>                 asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
> +                                        DEFINE_MSR_S                   \
>                                          "msr_s " __stringify(r##vh) ", %x0",\
>                                          ARM64_HAS_VIRT_HOST_EXTN)      \
>                                          : : "rZ" (__val));             \
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index f707fed5886f..1588ac3f3690 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -463,21 +463,58 @@
>
>  #include <linux/types.h>
>
> -asm(
> -"      .irp    num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
> -"      .equ    .L__reg_num_x\\num, \\num\n"
> -"      .endr\n"
> +#define ___MRS_MSR_S_REGNUM                                    \
> +"      .irp    num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n" \
> +"      .equ    .L__reg_num_x\\num, \\num\n"                    \
> +"      .endr\n"                                                \
>  "      .equ    .L__reg_num_xzr, 31\n"
> -"\n"
> -"      .macro  mrs_s, rt, sreg\n"
> -       __emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
> +
> +#define ___MRS_S                                               \
> +"      .macro  mrs_s, rt, sreg\n"                              \
> +       __emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))     \
>  "      .endm\n"
> -"\n"
> -"      .macro  msr_s, sreg, rt\n"
> -       __emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
> +
> +#define ___MSR_S                                               \
> +"      .macro  msr_s, sreg, rt\n"                              \
> +       __emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))     \
>  "      .endm\n"
> +
> +/*
> + * llvm-as doesn't allow macros defined in an asm block to be used in other
> + * asm blocks, which means we cannot define them globally.
> + */
> +#if !defined(CONFIG_CLANG_LTO)
> +asm(
> +       ___MRS_MSR_S_REGNUM
> +       ___MRS_S
> +       ___MSR_S
>  );
>
> +#undef  ___MRS_MSR_S_REGNUM
> +#define ___MRS_MSR_S_REGNUM
> +#undef  ___MRS_S
> +#define ___MRS_S
> +#undef  ___MSR_S
> +#define ___MSR_S
> +#endif
> +
> +#define DEFINE_MRS_S           \
> +       ___MRS_MSR_S_REGNUM     \
> +       ___MRS_S
> +
> +#define DEFINE_MSR_S           \
> +       ___MRS_MSR_S_REGNUM     \
> +       ___MSR_S
> +
> +
> +#define __mrs_s(r, v)                                          \
> +       DEFINE_MRS_S                                            \
> +"      mrs_s %0, " __stringify(r) : "=r" (v)
> +
> +#define __msr_s(r, v)                                          \
> +       DEFINE_MSR_S                                            \
> +"      msr_s " __stringify(r) ", %0" : : "r" (v)
> +
>  /*
>   * Unlike read_cpuid, calls to read_sysreg are never expected to be
>   * optimized away or replaced with synthetic values.
> @@ -502,15 +539,15 @@ asm(
>   * For registers without architectural names, or simply unsupported by
>   * GAS.
>   */
> -#define read_sysreg_s(r) ({                                            \
> -       u64 __val;                                                      \
> -       asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val));       \
> -       __val;                                                          \
> +#define read_sysreg_s(r) ({                                    \
> +       u64 __val;                                              \
> +       asm volatile(__mrs_s(r, __val));                        \
> +       __val;                                                  \
>  })
>
> -#define write_sysreg_s(v, r) do {                                      \
> -       u64 __val = (u64)(v);                                           \
> -       asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> +#define write_sysreg_s(v, r) do {                              \
> +       u64 __val = (u64)(v);                                   \
> +       asm volatile(__msr_s(r, __val));                        \
>  } while (0)
>
>  static inline void config_sctlr_el1(u32 clear, u32 set)
> --
> 2.15.0.403.gc27cc4dac6-goog
>



-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
> These mrs_s and msr_s macros in particular were preventing us from
> linking arm64 with Clang's integrated assembler, regardless of LTO.
> Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
> So while I appreciate how clever they are, they prevent us from
> assembling with Clang so I would like to see them go.

They're necessary to work with some currently-supported toolchains
(which don't support the s*_*_c*_c*_* syntax), so they're not going to
go completely.

If you could suggest something that clang might prefer, which doesn't
adversely affect GCC, I'm all ears.

Thanks,
Mark.

> 
> On Fri, Nov 3, 2017 at 10:12 AM, Sami Tolvanen <samitolvanen@google.com> wrote:
> > Clang's integrated assembler does not allow assembly macros defined
> > in one inline asm block using the .macro directive to be used across
> > separate asm blocks. LLVM developers consider this a feature and not a
> > bug, recommending code refactoring:
> >
> >   https://bugs.llvm.org/show_bug.cgi?id=19749
> >
> > As binutils doesn't allow macros to be redefined, this change adds C
> > preprocessor macros that define the assembly macros globally for binutils
> > and locally for clang's integrated assembler.
> >
> > Suggested-by: Greg Hackmann <ghackmann@google.com>
> > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> > ---
> >  arch/arm64/include/asm/kvm_hyp.h |  2 ++
> >  arch/arm64/include/asm/sysreg.h  | 71 ++++++++++++++++++++++++++++++----------
> >  2 files changed, 56 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> > index 4572a9b560fa..6840704ea894 100644
> > --- a/arch/arm64/include/asm/kvm_hyp.h
> > +++ b/arch/arm64/include/asm/kvm_hyp.h
> > @@ -29,6 +29,7 @@
> >         ({                                                              \
> >                 u64 reg;                                                \
> >                 asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
> > +                                        DEFINE_MRS_S                   \
> >                                          "mrs_s %0, " __stringify(r##vh),\
> >                                          ARM64_HAS_VIRT_HOST_EXTN)      \
> >                              : "=r" (reg));                             \
> > @@ -39,6 +40,7 @@
> >         do {                                                            \
> >                 u64 __val = (u64)(v);                                   \
> >                 asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
> > +                                        DEFINE_MSR_S                   \
> >                                          "msr_s " __stringify(r##vh) ", %x0",\
> >                                          ARM64_HAS_VIRT_HOST_EXTN)      \
> >                                          : : "rZ" (__val));             \
> > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > index f707fed5886f..1588ac3f3690 100644
> > --- a/arch/arm64/include/asm/sysreg.h
> > +++ b/arch/arm64/include/asm/sysreg.h
> > @@ -463,21 +463,58 @@
> >
> >  #include <linux/types.h>
> >
> > -asm(
> > -"      .irp    num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
> > -"      .equ    .L__reg_num_x\\num, \\num\n"
> > -"      .endr\n"
> > +#define ___MRS_MSR_S_REGNUM                                    \
> > +"      .irp    num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n" \
> > +"      .equ    .L__reg_num_x\\num, \\num\n"                    \
> > +"      .endr\n"                                                \
> >  "      .equ    .L__reg_num_xzr, 31\n"
> > -"\n"
> > -"      .macro  mrs_s, rt, sreg\n"
> > -       __emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
> > +
> > +#define ___MRS_S                                               \
> > +"      .macro  mrs_s, rt, sreg\n"                              \
> > +       __emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))     \
> >  "      .endm\n"
> > -"\n"
> > -"      .macro  msr_s, sreg, rt\n"
> > -       __emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
> > +
> > +#define ___MSR_S                                               \
> > +"      .macro  msr_s, sreg, rt\n"                              \
> > +       __emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))     \
> >  "      .endm\n"
> > +
> > +/*
> > + * llvm-as doesn't allow macros defined in an asm block to be used in other
> > + * asm blocks, which means we cannot define them globally.
> > + */
> > +#if !defined(CONFIG_CLANG_LTO)
> > +asm(
> > +       ___MRS_MSR_S_REGNUM
> > +       ___MRS_S
> > +       ___MSR_S
> >  );
> >
> > +#undef  ___MRS_MSR_S_REGNUM
> > +#define ___MRS_MSR_S_REGNUM
> > +#undef  ___MRS_S
> > +#define ___MRS_S
> > +#undef  ___MSR_S
> > +#define ___MSR_S
> > +#endif
> > +
> > +#define DEFINE_MRS_S           \
> > +       ___MRS_MSR_S_REGNUM     \
> > +       ___MRS_S
> > +
> > +#define DEFINE_MSR_S           \
> > +       ___MRS_MSR_S_REGNUM     \
> > +       ___MSR_S
> > +
> > +
> > +#define __mrs_s(r, v)                                          \
> > +       DEFINE_MRS_S                                            \
> > +"      mrs_s %0, " __stringify(r) : "=r" (v)
> > +
> > +#define __msr_s(r, v)                                          \
> > +       DEFINE_MSR_S                                            \
> > +"      msr_s " __stringify(r) ", %0" : : "r" (v)
> > +
> >  /*
> >   * Unlike read_cpuid, calls to read_sysreg are never expected to be
> >   * optimized away or replaced with synthetic values.
> > @@ -502,15 +539,15 @@ asm(
> >   * For registers without architectural names, or simply unsupported by
> >   * GAS.
> >   */
> > -#define read_sysreg_s(r) ({                                            \
> > -       u64 __val;                                                      \
> > -       asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val));       \
> > -       __val;                                                          \
> > +#define read_sysreg_s(r) ({                                    \
> > +       u64 __val;                                              \
> > +       asm volatile(__mrs_s(r, __val));                        \
> > +       __val;                                                  \
> >  })
> >
> > -#define write_sysreg_s(v, r) do {                                      \
> > -       u64 __val = (u64)(v);                                           \
> > -       asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> > +#define write_sysreg_s(v, r) do {                              \
> > +       u64 __val = (u64)(v);                                   \
> > +       asm volatile(__msr_s(r, __val));                        \
> >  } while (0)
> >
> >  static inline void config_sctlr_el1(u32 clear, u32 set)
> > --
> > 2.15.0.403.gc27cc4dac6-goog
> >
> 
> 
> 
> -- 
> Thanks,
> ~Nick Desaulniers
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Nick Desaulniers]

On Fri, Nov 3, 2017 at 11:06 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 03, 2017 at 10:53:08AM -0700, Nick Desaulniers wrote:
>> These mrs_s and msr_s macros in particular were preventing us from
>> linking arm64 with Clang's integrated assembler, regardless of LTO.
>> Those macros ran into: https://bugs.llvm.org/show_bug.cgi?id=19749.
>> So while I appreciate how clever they are, they prevent us from
>> assembling with Clang so I would like to see them go.
>
> They're necessary to work with some currently-supported toolchains
> (which don't support the s*_*_c*_c*_* syntax), so they're not going to
> go completely.
>
> If you could suggest something that clang might prefer, which doesn't
> adversely affect GCC, I'm all ears.

I wasn't clear in my point; I recognize what they do and agree that
they are needed.

More specifically, my problem is the use of .macro assembly
directives, since Clang "considers it a feature" not to let you invoke
a .macro defined in one inline asm block from another asm inline
block.

So I would like to see *the use of .macro in separate inline asm
blocks within mrs_s and msr_s c-preprocessor macros go.*

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactoring:
> 
>   https://bugs.llvm.org/show_bug.cgi?id=19749

I agree that this a construct to be avoided if possible.

[...]

> +/*
> + * llvm-as doesn't allow macros defined in an asm block to be used in other
> + * asm blocks, which means we cannot define them globally.
> + */
> +#if !defined(CONFIG_CLANG_LTO)

Can the integrated assembler not be used in the absence of LTO?

> +asm(
> +	___MRS_MSR_S_REGNUM
> +	___MRS_S
> +	___MSR_S
>  );
>  
> +#undef  ___MRS_MSR_S_REGNUM
> +#define ___MRS_MSR_S_REGNUM
> +#undef  ___MRS_S
> +#define ___MRS_S
> +#undef  ___MSR_S
> +#define ___MSR_S
> +#endif

It would be much nicer if we could use one code path regardless here.

Can we fold the asm macros into the CPP macros somehow instead?

IIRC the only reason we use asm macros for the inline assembly case was
because we couldn't figure out how to token-paste with %N in CPP, but
there might be another way around that.

Thanks,
Mark.

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Yury Norov]

Hi Sami,

(CC Andi Kleen, Alex Matveev, Maxim Kuvyrkov)

On Fri, Nov 03, 2017 at 10:12:01AM -0700, Sami Tolvanen wrote:
> Clang's integrated assembler does not allow assembly macros defined
> in one inline asm block using the .macro directive to be used across
> separate asm blocks. LLVM developers consider this a feature and not a
> bug, recommending code refactoring:
> 
>   https://bugs.llvm.org/show_bug.cgi?id=19749
> 
> As binutils doesn't allow macros to be redefined, this change adds C
> preprocessor macros that define the assembly macros globally for binutils
> and locally for clang's integrated assembler.

This macros are also the problem for gcc and ld.bfd if we try to
enable LTO.

The patch below uses trick with undefining mrs_s/msr_s immediately
after use to solve the problem. It works for both gcc and clang.

There's the series from Andi Kleen that enables LTO for Linux on x86:
https://lwn.net/Articles/512548/
https://github.com/andikleen/linux-misc/tree/lto-411-1

It has solved many problems you also try to solve, and some patches
are looking very similar. 

At now we have different patchsets for gcc and clang, and it would be
better to have them together. One thing I'm worried is that you introduce
CONFIG_CLANG_LTO and use it for all cases, including that where more
generic CONFIG_LTO should be used.

I think we'd also discuss it here.
________

>From c939344c726e8ae6b28012ad2807c63b54175e40 Mon Sep 17 00:00:00 2001
From: Alex Matveev <alxmtvv@gmail.com>
Date: Tue, 7 Nov 2017 01:06:33 +0000
Subject: [PATCH] arm64: make mrs_s and msr_s macros work with LTO

Use UNDEFINE_MRS_S and UNDEFINE_MSR_S to define corresponding macros
in-place and workaround gcc and clang limitations on redefining macros
across different assembler blocks.

Signed-off-by: Alex Matveev <alxmtvv@gmail.com>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
 arch/arm64/include/asm/kvm_hyp.h |  8 ++++--
 arch/arm64/include/asm/sysreg.h  | 55 +++++++++++++++++++++++++++-------------
 2 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 4572a9b560fa..20bfb8e676e0 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -29,7 +29,9 @@
 	({								\
 		u64 reg;						\
 		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
-					 "mrs_s %0, " __stringify(r##vh),\
+					 DEFINE_MRS_S			\
+					 "mrs_s %0, " __stringify(r##vh) "\n"\
+					 UNDEFINE_MRS_S,		\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 			     : "=r" (reg));				\
 		reg;							\
@@ -39,7 +41,9 @@
 	do {								\
 		u64 __val = (u64)(v);					\
 		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
-					 "msr_s " __stringify(r##vh) ", %x0",\
+					 DEFINE_MSR_S			\
+					 "msr_s " __stringify(r##vh) ", %x0\n"\
+					 UNDEFINE_MSR_S,		\
 					 ARM64_HAS_VIRT_HOST_EXTN)	\
 					 : : "rZ" (__val));		\
 	} while (0)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f707fed5886f..a69b0ca9a3b4 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -463,20 +463,39 @@
 
 #include <linux/types.h>
 
-asm(
-"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
-"	.equ	.L__reg_num_x\\num, \\num\n"
-"	.endr\n"
+#define __DEFINE_MRS_MSR_S_REGNUM				\
+"	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n" \
+"	.equ	.L__reg_num_x\\num, \\num\n"			\
+"	.endr\n"						\
 "	.equ	.L__reg_num_xzr, 31\n"
-"\n"
-"	.macro	mrs_s, rt, sreg\n"
-	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define DEFINE_MRS_S						\
+	__DEFINE_MRS_MSR_S_REGNUM				\
+"	.macro	mrs_s, rt, sreg\n"				\
+	__emit_inst(0xd5200000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
-"\n"
-"	.macro	msr_s, sreg, rt\n"
-	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))
+
+#define DEFINE_MSR_S						\
+	__DEFINE_MRS_MSR_S_REGNUM				\
+"	.macro	msr_s, sreg, rt\n"				\
+	__emit_inst(0xd5000000|(\\sreg)|(.L__reg_num_\\rt))	\
 "	.endm\n"
-);
+
+#define UNDEFINE_MRS_S						\
+"	.purgem	mrs_s\n"
+
+#define UNDEFINE_MSR_S						\
+"	.purgem	msr_s\n"
+
+#define __mrs_s(r, v)						\
+	DEFINE_MRS_S						\
+"	mrs_s %0, " __stringify(r) "\n"				\
+	UNDEFINE_MRS_S : "=r" (v)
+
+#define __msr_s(r, v)						\
+	DEFINE_MSR_S						\
+"	msr_s " __stringify(r) ", %x0\n"			\
+	UNDEFINE_MSR_S : : "rZ" (v)
 
 /*
  * Unlike read_cpuid, calls to read_sysreg are never expected to be
@@ -502,15 +521,15 @@ asm(
  * For registers without architectural names, or simply unsupported by
  * GAS.
  */
-#define read_sysreg_s(r) ({						\
-	u64 __val;							\
-	asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val));	\
-	__val;								\
+#define read_sysreg_s(r) ({					\
+	u64 __val;						\
+	asm volatile(__mrs_s(r, __val));			\
+	__val;							\
 })
 
-#define write_sysreg_s(v, r) do {					\
-	u64 __val = (u64)(v);						\
-	asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val));	\
+#define write_sysreg_s(v, r) do {				\
+	u64 __val = (u64)(v);					\
+	asm volatile(__msr_s(r, __val));			\
 } while (0)
 
 static inline void config_sctlr_el1(u32 clear, u32 set)
-- 
2.11.0

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Andi Kleen]

> There's the series from Andi Kleen that enables LTO for Linux on x86:
> https://lwn.net/Articles/512548/
> https://github.com/andikleen/linux-misc/tree/lto-411-1
> 
> It has solved many problems you also try to solve, and some patches
> are looking very similar. 
> 
> At now we have different patchsets for gcc and clang, and it would be
> better to have them together. One thing I'm worried is that you introduce
> CONFIG_CLANG_LTO and use it for all cases, including that where more
> generic CONFIG_LTO should be used.

Yes would be good to merge the two. I've been looking at updating
my old one.

I don't cover any ARM code, but lots of generic code. My patches
also worked on MIPS at least.

There's also older patches to enable single-pass-linking for kallsyms,
which is extremly useful for LTO build performance.

-Andi

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Maxim Kuvyrkov]

> On Nov 9, 2017, at 3:02 AM, Andi Kleen <ak@linux.intel.com> wrote:
> 
>> There's the series from Andi Kleen that enables LTO for Linux on x86:
>> https://lwn.net/Articles/512548/
>> https://github.com/andikleen/linux-misc/tree/lto-411-1
>> 
>> It has solved many problems you also try to solve, and some patches
>> are looking very similar. 
>> 
>> At now we have different patchsets for gcc and clang, and it would be
>> better to have them together. One thing I'm worried is that you introduce
>> CONFIG_CLANG_LTO and use it for all cases, including that where more
>> generic CONFIG_LTO should be used.
> 
> Yes would be good to merge the two. I've been looking at updating
> my old one.
> 
> I don't cover any ARM code, but lots of generic code. My patches
> also worked on MIPS at least.
> 
> There's also older patches to enable single-pass-linking for kallsyms,
> which is extremly useful for LTO build performance.

[Yury, thanks for the CC:]

Chiming in from the toolchain side, Linaro's Toolchain team will try to help with any GCC or Clang issues that are exposed by building kernel with LTO on arm64 / arm.

Regarding CONFIG_* options, I would expect most of the configuration changes to be equally valid for both GCC's and Clang's LTO support.  Sami, I don't think it's fair to ask you to support both Clang and GCC in your patchset, but, where changes are obviously toolchain-agnostic, could you use CONFIG_LTO?  And use CONFIG_LTO_CLANG for Clang-specific parts?

This way we will be able to avoid most of the refactoring when adding support for GCC's LTO.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Sami Tolvanen]

On Thu, Nov 09, 2017 at 07:48:06AM +0300, Maxim Kuvyrkov wrote:
> Regarding CONFIG_* options, I would expect most of the configuration
> changes to be equally valid for both GCC's and Clang's LTO support.
> Sami, I don't think it's fair to ask you to support both Clang and GCC in
> your patchset, but, where changes are obviously toolchain-agnostic, could
> you use CONFIG_LTO?  And use CONFIG_LTO_CLANG for Clang-specific parts?

Sure, using CONFIG_LTO for common code and CONFIG_LTO_CLANG for clang-
specific parts sounds good.

Sami

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Sami Tolvanen]

On Wed, Nov 08, 2017 at 04:02:22PM -0800, Andi Kleen wrote:
> There's also older patches to enable single-pass-linking for kallsyms,
> which is extremly useful for LTO build performance.

Excellent, can you point me to the patch in question?

I worked around the build performance problem by reusing vmlinux.o for
kallsyms instead of linking all bitcode again in each step. I'm not sure
if this is feasible with gcc.

Sami

Re: [PATCH 13/15] arm64: fix mrs_s/msr_s macros for clang LTO

[Sami Tolvanen]

On Wed, Nov 08, 2017 at 12:25:55PM +0300, Yury Norov wrote:
> The patch below uses trick with undefining mrs_s/msr_s immediately
> after use to solve the problem. It works for both gcc and clang.

Great, looks good to me! I tested the patch with LTO and clang's integrated
assembler seems to be happy with it.

> It has solved many problems you also try to solve, and some patches
> are looking very similar.

I haven't had a closer look at the gcc LTO patches yet, but I am definitely
all for using common code where possible.

Sami 

[PATCH 14/15] arm64: crypto: disable LTO for aes-ce-cipher.c

[Sami Tolvanen]

CONFIG_CLANG_LTO requires the use of clang's integrated assembler, which
doesn't understand the inline assembly in aes-ce-cipher.c. Disable LTO for
the file to work around the issue.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/crypto/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index b5edc5918c28..0edaef43a1d4 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_CRYPTO_CRC32_ARM64_CE) += crc32-ce.o
 crc32-ce-y:= crc32-ce-core.o crc32-ce-glue.o
 
 obj-$(CONFIG_CRYPTO_AES_ARM64_CE) += aes-ce-cipher.o
-CFLAGS_aes-ce-cipher.o += -march=armv8-a+crypto
+CFLAGS_aes-ce-cipher.o += -march=armv8-a+crypto $(DISABLE_LTO)
 
 obj-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
 aes-ce-ccm-y := aes-ce-ccm-glue.o aes-ce-ccm-core.o
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 14/15] arm64: crypto: disable LTO for aes-ce-cipher.c

[Ard Biesheuvel]

On 3 November 2017 at 17:12, Sami Tolvanen <samitolvanen@google.com> wrote:
> CONFIG_CLANG_LTO requires the use of clang's integrated assembler, which
> doesn't understand the inline assembly in aes-ce-cipher.c. Disable LTO for
> the file to work around the issue.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  arch/arm64/crypto/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
> index b5edc5918c28..0edaef43a1d4 100644
> --- a/arch/arm64/crypto/Makefile
> +++ b/arch/arm64/crypto/Makefile
> @@ -24,7 +24,7 @@ obj-$(CONFIG_CRYPTO_CRC32_ARM64_CE) += crc32-ce.o
>  crc32-ce-y:= crc32-ce-core.o crc32-ce-glue.o
>
>  obj-$(CONFIG_CRYPTO_AES_ARM64_CE) += aes-ce-cipher.o
> -CFLAGS_aes-ce-cipher.o += -march=armv8-a+crypto
> +CFLAGS_aes-ce-cipher.o += -march=armv8-a+crypto $(DISABLE_LTO)
>
>  obj-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
>  aes-ce-ccm-y := aes-ce-ccm-glue.o aes-ce-ccm-core.o
> --
> 2.15.0.403.gc27cc4dac6-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 15/15] arm64: select ARCH_SUPPORTS_CLANG_LTO

[Sami Tolvanen]

Allow CONFIG_CLANG_LTO to be enabled for the architecture.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a301fdc90319..6ae31f0c58ee 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -23,6 +23,7 @@ config ARM64
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG if ACPI_APEI_SEA
 	select ARCH_USE_CMPXCHG_LOCKREF
+	select ARCH_SUPPORTS_CLANG_LTO
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 	select ARCH_SUPPORTS_ATOMIC_RMW
 	select ARCH_SUPPORTS_NUMA_BALANCING
-- 
2.15.0.403.gc27cc4dac6-goog

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

Hi,

On Fri, Nov 03, 2017 at 10:11:44AM -0700, Sami Tolvanen wrote:
> This series adds build system support for compiling the kernel with clang
> Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in
> for linking. Some background for clang's LTO support is available here:
> 
>   https://llvm.org/docs/LinkTimeOptimization.html
> 
> With -flto, clang produces LLVM bitcode instead of object files, and
> the compilation to native code happens at link time. In addition, clang
> cannot use an external assembler for inline assembly when LTO is enabled,
> which causes further compatibility issues.
> 
> The patches in this series remove intermediate linking steps when LTO is
> used, postpone processing done on object files until after the LTO link
> step, add workarounds for GNU gold incompatibilities, and address inline
> assembly incompatibilities for arm64.
> 
> These changes allow arm64 defconfig to be compiled with LTO, but other
> architectures are not enabled until compatibility issues have been
> addressed. In particular, x86 inline assembly doesn't currently compile
> with clang's integrated assembler due to this LLVM bug:
> 
>   https://bugs.llvm.org/show_bug.cgi?id=24487
> 
> Due to recent bug fixes in the toolchain, it's recommended to use clang
> 5.0 or later, and GNU gold from binutils 2.27 or later

Which tree are you testing with?

I had a go building the arm64 for/next/core branch defconfig using clang
5.0.0 from llvm.org, with the Linaro 17.05 toolchain's binutils
(2.27.0.20161019), and I hit what appears to be a compiler bug quite
quickly.

I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
there's build system help to avoid needing that?

----
[mark@lakrids:~/src/linux]% uselinaro 17.05 usellvm 5.0.0 make CROSS_COMPILE=aarch64-linux-gnu- CC=clang  ARCH=arm64 
Segmentation fault
arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
arch/arm64/Makefile:48: Detected assembler with broken .inst; disassembly will be unreliable
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
  CC      arch/arm64/crypto/aes-ce-cipher.o
fatal error: error in backend: Do not know how to split the result of this operator!

clang-5.0: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 5.0.0 (tags/RELEASE_500/final)
Target: aarch64--linux-gnu
Thread model: posix
InstalledDir: /mnt/data/opt/toolchain/llvm/5.0.0/bin
clang-5.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang-5.0: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-5.0: note: diagnostic msg: /tmp/aes-ce-cipher-7850ed.c
clang-5.0: note: diagnostic msg: /tmp/aes-ce-cipher-7850ed.sh
clang-5.0: note: diagnostic msg: 

********************
scripts/Makefile.build:313: recipe for target 'arch/arm64/crypto/aes-ce-cipher.o' failed
make[1]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 70
Makefile:1019: recipe for target 'arch/arm64/crypto' failed
make: *** [arch/arm64/crypto] Error 2
----

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Nick Desaulniers]

On Fri, Nov 3, 2017 at 10:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
> there's build system help to avoid needing that?

Gah!  So a BIG difference with Clang vs GCC for cross compiling is
that Clang by default ships with all backends enabled, and uses a
`-target <triple>` CFLAG to determine the arch to cross compile for,
while GCC is configured at compile time to support one back end, IIUC.
Clang _can_ be built with all other back ends disabled but one, but I
have a problem with this approach:  distributions of Clang are rarely
configured this way (all backends enabled by default), and it seems we
just found this past week that Clang if configured with just one
backend, it will silently ignore -target flags for other backends and
generate code for the configured backend (this led to:
https://lkml.org/lkml/2017/11/2/892).  I consider this a bug in Clang,
so I just filed: https://bugs.llvm.org/show_bug.cgi?id=35196

>   CC      arch/arm64/crypto/aes-ce-cipher.o
> fatal error: error in backend: Do not know how to split the result of this operator!

Yep, we've seen this.  It was the FINAL bug in Clang for compiling the
kernel for arm64.  It was recently fixed upstream in llvm by
gbiv@google.com, but so recent that you'll need to either compiler
Clang from source from ToT or work around it like we have in Android
with:
https://android.googlesource.com/kernel/msm/+/9093342a0186dad05095b70f1806938310ace6e7

aka patch 7 in this series.

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 11:07:04AM -0700, Nick Desaulniers wrote:
> On Fri, Nov 3, 2017 at 10:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
> > there's build system help to avoid needing that?
> 
> Gah!  So a BIG difference with Clang vs GCC for cross compiling is
> that Clang by default ships with all backends enabled, and uses a
> `-target <triple>` CFLAG to determine the arch to cross compile for,
> while GCC is configured at compile time to support one back end, IIUC.

Yup.

I initally tried passing CC=clang\ --target=aarch64-linux-gnu

... but since that conflicts with CROSS_COMPILE, you then have to
override AS, LD, OBJCOPY, etc, separately too.

This is a little less than ideal. :/

> Clang _can_ be built with all other back ends disabled but one, but I
> have a problem with this approach:  distributions of Clang are rarely
> configured this way (all backends enabled by default), and it seems we
> just found this past week that Clang if configured with just one
> backend, it will silently ignore -target flags for other backends and
> generate code for the configured backend (this led to:
> https://lkml.org/lkml/2017/11/2/892).  I consider this a bug in Clang,
> so I just filed: https://bugs.llvm.org/show_bug.cgi?id=35196

Ouch. Thanks for attacking that.

> >   CC      arch/arm64/crypto/aes-ce-cipher.o
> > fatal error: error in backend: Do not know how to split the result of this operator!
> 
> Yep, we've seen this.  It was the FINAL bug in Clang for compiling the
> kernel for arm64.  It was recently fixed upstream in llvm by
> gbiv@google.com, but so recent that you'll need to either compiler
> Clang from source from ToT or work around it like we have in Android
> with:
> https://android.googlesource.com/kernel/msm/+/9093342a0186dad05095b70f1806938310ace6e7

Sure. I can live with patch 7 for now, assuming there's nothing else
lurking in the shadows.

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Nick Desaulniers]

On Fri, Nov 3, 2017 at 11:29 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 03, 2017 at 11:07:04AM -0700, Nick Desaulniers wrote:
>> On Fri, Nov 3, 2017 at 10:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
>> > there's build system help to avoid needing that?
>>
>> Gah!  So a BIG difference with Clang vs GCC for cross compiling is
>> that Clang by default ships with all backends enabled, and uses a
>> `-target <triple>` CFLAG to determine the arch to cross compile for,
>> while GCC is configured at compile time to support one back end, IIUC.
>
> Yup.
>
> I initally tried passing CC=clang\ --target=aarch64-linux-gnu
>
> ... but since that conflicts with CROSS_COMPILE, you then have to
> override AS, LD, OBJCOPY, etc, separately too.

make CC=clang CROSS_COMPILE=aarch64-linux-gnu-

I think you may need a trailing hyphen on your target as it gets
prefixed onto as and ld:

Makefile:

 348 # Make variables (CC, etc...)
 349 AS    = $(CROSS_COMPILE)as
 350 LD    = $(CROSS_COMPILE)ld

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 11:36:33AM -0700, Nick Desaulniers wrote:
> On Fri, Nov 3, 2017 at 11:29 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Nov 03, 2017 at 11:07:04AM -0700, Nick Desaulniers wrote:
> >> On Fri, Nov 3, 2017 at 10:51 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
> >> > there's build system help to avoid needing that?
> >>
> >> Gah!  So a BIG difference with Clang vs GCC for cross compiling is
> >> that Clang by default ships with all backends enabled, and uses a
> >> `-target <triple>` CFLAG to determine the arch to cross compile for,
> >> while GCC is configured at compile time to support one back end, IIUC.
> >
> > Yup.
> >
> > I initally tried passing CC=clang\ --target=aarch64-linux-gnu
> >
> > ... but since that conflicts with CROSS_COMPILE, you then have to
> > override AS, LD, OBJCOPY, etc, separately too.
> 
> make CC=clang CROSS_COMPILE=aarch64-linux-gnu-
> 
> I think you may need a trailing hyphen on your target as it gets
> prefixed onto as and ld:
> 
> Makefile:
> 
>  348 # Make variables (CC, etc...)
>  349 AS    = $(CROSS_COMPILE)as
>  350 LD    = $(CROSS_COMPILE)ld

I thought CC=clang CROSS_COMPILE=foo- would result in foo-clang, but
evidently this is not the case.

I must've meseed up something else; sorry for the noise.

Thanks for correcting me; now I can go delete my wrapper. :)

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Matthias Kaehlcke]

Hi Mark,

El Fri, Nov 03, 2017 at 05:51:56PM +0000 Mark Rutland ha dit:

> On Fri, Nov 03, 2017 at 10:11:44AM -0700, Sami Tolvanen wrote:
> > This series adds build system support for compiling the kernel with clang
> > Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in
> > for linking. Some background for clang's LTO support is available here:
> > 
> >   https://llvm.org/docs/LinkTimeOptimization.html
> > 
> > With -flto, clang produces LLVM bitcode instead of object files, and
> > the compilation to native code happens at link time. In addition, clang
> > cannot use an external assembler for inline assembly when LTO is enabled,
> > which causes further compatibility issues.
> > 
> > The patches in this series remove intermediate linking steps when LTO is
> > used, postpone processing done on object files until after the LTO link
> > step, add workarounds for GNU gold incompatibilities, and address inline
> > assembly incompatibilities for arm64.
> > 
> > These changes allow arm64 defconfig to be compiled with LTO, but other
> > architectures are not enabled until compatibility issues have been
> > addressed. In particular, x86 inline assembly doesn't currently compile
> > with clang's integrated assembler due to this LLVM bug:
> > 
> >   https://bugs.llvm.org/show_bug.cgi?id=24487
> > 
> > Due to recent bug fixes in the toolchain, it's recommended to use clang
> > 5.0 or later, and GNU gold from binutils 2.27 or later
> 
> Which tree are you testing with?

In general upstream should be a good starting point.

> I had a go building the arm64 for/next/core branch defconfig using clang
> 5.0.0 from llvm.org, with the Linaro 17.05 toolchain's binutils
> (2.27.0.20161019), and I hit what appears to be a compiler bug quite
> quickly.
> 
> I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
> there's build system help to avoid needing that?
> 
> ----
> [mark@lakrids:~/src/linux]% uselinaro 17.05 usellvm 5.0.0 make CROSS_COMPILE=aarch64-linux-gnu- CC=clang  ARCH=arm64 
> Segmentation fault
> arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
> arch/arm64/Makefile:48: Detected assembler with broken .inst;
> disassembly will be unreliable

This should be fixed by https://patchwork.kernel.org/patch/10039329/
and https://patchwork.kernel.org/patch/10030583/

Unfortunately we didn't encounter these earlier, in Chrome OS this
was/is hidden by invoking an architecture aware wrapper instead of
bare clang :(

>   CHK     include/config/kernel.release
>   CHK     include/generated/uapi/linux/version.h
>   CHK     include/generated/utsrelease.h
>   CHK     include/generated/bounds.h
>   CHK     include/generated/timeconst.h
>   CHK     include/generated/asm-offsets.h
>   CALL    scripts/checksyscalls.sh
>   CHK     scripts/mod/devicetable-offsets.h
>   CHK     include/generated/compile.h
>   CC      arch/arm64/crypto/aes-ce-cipher.o
> fatal error: error in backend: Do not know how to split the result of this operator!
> 
> clang-5.0: error: clang frontend command failed with exit code 70 (use -v to see invocation)
> clang version 5.0.0 (tags/RELEASE_500/final)
> Target: aarch64--linux-gnu
> Thread model: posix
> InstalledDir: /mnt/data/opt/toolchain/llvm/5.0.0/bin
> clang-5.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
> clang-5.0: note: diagnostic msg: 
> ********************
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-5.0: note: diagnostic msg: /tmp/aes-ce-cipher-7850ed.c
> clang-5.0: note: diagnostic msg: /tmp/aes-ce-cipher-7850ed.sh
> clang-5.0: note: diagnostic msg: 
> 
> ********************
> scripts/Makefile.build:313: recipe for target 'arch/arm64/crypto/aes-ce-cipher.o' failed
> make[1]: *** [arch/arm64/crypto/aes-ce-cipher.o] Error 70
> Makefile:1019: recipe for target 'arch/arm64/crypto' failed
> make: *** [arch/arm64/crypto] Error 2

This is fixed in newer clang versions, otherwise you need

[PATCH 07/15] arm64: use -mno-implicit-float instead of
-mgeneral-regs-only

of this series.

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 05:51:56PM +0000, Mark Rutland wrote:
> Hi,
> 
> On Fri, Nov 03, 2017 at 10:11:44AM -0700, Sami Tolvanen wrote:
> > This series adds build system support for compiling the kernel with clang
> > Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in
> > for linking. Some background for clang's LTO support is available here:
> > 
> >   https://llvm.org/docs/LinkTimeOptimization.html
> > 
> > With -flto, clang produces LLVM bitcode instead of object files, and
> > the compilation to native code happens at link time. In addition, clang
> > cannot use an external assembler for inline assembly when LTO is enabled,
> > which causes further compatibility issues.
> > 
> > The patches in this series remove intermediate linking steps when LTO is
> > used, postpone processing done on object files until after the LTO link
> > step, add workarounds for GNU gold incompatibilities, and address inline
> > assembly incompatibilities for arm64.
> > 
> > These changes allow arm64 defconfig to be compiled with LTO, but other
> > architectures are not enabled until compatibility issues have been
> > addressed. In particular, x86 inline assembly doesn't currently compile
> > with clang's integrated assembler due to this LLVM bug:
> > 
> >   https://bugs.llvm.org/show_bug.cgi?id=24487
> > 
> > Due to recent bug fixes in the toolchain, it's recommended to use clang
> > 5.0 or later, and GNU gold from binutils 2.27 or later
> 
> Which tree are you testing with?
> 
> I had a go building the arm64 for/next/core branch defconfig using clang
> 5.0.0 from llvm.org, with the Linaro 17.05 toolchain's binutils
> (2.27.0.20161019), and I hit what appears to be a compiler bug quite
> quickly.

So as per my reply to patch 7, it looks like this series addresses this
case.

What's the minimum set of patches necessary to work with clang (ignoring
LTO)?

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Nick Desaulniers]

On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland <mark.rutland@arm.com> wrote:
ently compile
> What's the minimum set of patches necessary to work with clang (ignoring
> LTO)?

If you have a build of clang-5, then just patch 7 in this series to
work around the last compiler bug.  If you build clang from source
from master, ToT, for arm64, then none. :)

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 11:11:45AM -0700, Nick Desaulniers wrote:
> On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> ently compile
> > What's the minimum set of patches necessary to work with clang (ignoring
> > LTO)?
> 
> If you have a build of clang-5, then just patch 7 in this series to
> work around the last compiler bug.  If you build clang from source
> from master, ToT, for arm64, then none. :)

Thanks for the pointers.

With patch 7 I can build a defconfig from the arm64 for-next/core
branch, but it panics (in hyp) on my Juno R1 when initialising hyp.

If I build that branch with the Linaro 17.05 GCC 6.3.1 toolchain, I get
all the way to userspace.

The same is true (for both compilers) with v4.14-rc7.

I guess that in Google you haven't tested on a platform with EL2
available?

[    1.301280] kvm [1]: 8-bit VMID
[    1.304416] kvm [1]: IDMAP page: 809e2000
[    1.308406] kvm [1]: HYP VA range: 800000000000:ffffffffffff
[    1.315077] kvm [1]: Hyp mode initialized successfully
[    1.320211] Kernel panic - not syncing: HYP panic:
[    1.320211] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
[    1.320211] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
[    1.320211] VCPU:000804fc20001221
[    1.320211]
[    1.341947] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
[    1.348675] Hardware name: ARM Juno development board (r1) (DT)
[    1.354543] Call trace:
[    1.356977] [<ffff000008088ea4>] dump_backtrace+0x0/0x34c
[    1.362333] [<ffff000008089208>] show_stack+0x18/0x20
[    1.367345] [<ffff0000089c73ec>] dump_stack+0xc4/0xfc
[    1.372357] [<ffff0000080c8e1c>] panic+0x138/0x2b4
[    1.377109] [<ffff0000080c8ce4>] panic+0x0/0x2b4
[    1.381692] SMP: stopping secondary CPUs
[    2.571295] SMP: failed to stop secondary CPUs 0-3,5
[    2.576214] Kernel Offset: disabled
[    2.579670] CPU features: 0x002086
[    2.583039] Memory Limit: none
[    2.586073] ---[ end Kernel panic - not syncing: HYP panic:
[    2.586073] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
[    2.586073] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
[    2.586073] VCPU:000804fc20001221

The PC in question is:

[mark@lakrids:~/src/linux]% uselinaro 17.05 aarch64-linux-gnu-addr2line -ife vmlinux ffff0000089e6fd8
__init_stage2_translation
/home/mark/src/linux/arch/arm64/kvm/hyp/s2-setup.c:38

AFAICT, the generated assembly is only using PC-relative branches, and
no absolute relocations:

0000000000000000 <__init_stage2_translation>:
   0:	d5380709 	mrs	x9, id_aa64mmfr0_el1
   4:	12000928 	and	w8, w9, #0x7
   8:	7100111f 	cmp	w8, #0x4
   c:	d3700928 	ubfiz	x8, x9, #16, #3
  10:	54000188 	b.hi	40 <__init_stage2_translation+0x40>
  14:	9000000a 	adrp	x10, 0 <__init_stage2_translation>
  18:	92400929 	and	x9, x9, #0x7
  1c:	9100014a 	add	x10, x10, #0x0
  20:	f869794b 	ldr	x11, [x10,x9,lsl #3]
  24:	52800509 	mov	w9, #0x28                  	// #40
  28:	321b03e0 	orr	w0, wzr, #0x20
  2c:	321b03ea 	orr	w10, wzr, #0x20
  30:	d61f0160 	br	x11
  34:	52800480 	mov	w0, #0x24                  	// #36
  38:	321e0bea 	orr	w10, wzr, #0x1c
  3c:	14000008 	b	5c <__init_stage2_translation+0x5c>
  40:	321c07e9 	orr	w9, wzr, #0x30
  44:	14000004 	b	54 <__init_stage2_translation+0x54>
  48:	52800549 	mov	w9, #0x2a                  	// #42
  4c:	14000002 	b	54 <__init_stage2_translation+0x54>
  50:	52800589 	mov	w9, #0x2c                  	// #44
  54:	321d07ea 	orr	w10, wzr, #0x18
  58:	2a0903e0 	mov	w0, w9
  5c:	aa080148 	orr	x8, x10, x8
  60:	929957ea 	mov	x10, #0xffffffffffff3540    	// #-51904
  64:	d5380729 	mrs	x9, id_aa64mmfr1_el1
  68:	f2b0000a 	movk	x10, #0x8000, lsl #16
  6c:	d538072b 	mrs	x11, id_aa64mmfr1_el1
  70:	9148014c 	add	x12, x10, #0x200, lsl #12
  74:	f2400d3f 	tst	x9, #0xf
  78:	927c0d69 	and	x9, x11, #0xf0
  7c:	9a8c014a 	csel	x10, x10, x12, eq
  80:	f100813f 	cmp	x9, #0x20
  84:	aa0a0108 	orr	x8, x8, x10
  88:	1a9f17e9 	cset	w9, eq
  8c:	aa094d08 	orr	x8, x8, x9, lsl #19
  90:	d51c2148 	msr	vtcr_el2, x8
  94:	d65f03c0 	ret

... so I guess something is going wrong around kvm_call_hyp() where this
is called from EL1.

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 07:26:35PM +0000, Mark Rutland wrote:
> I guess that in Google you haven't tested on a platform with EL2
> available?

Correct. I'll look into this and include a fix in v2. Does this work on a
clang build without LTO?

Sami

Re: [PATCH 00/15] Add support for clang LTO

[Mark Rutland]

On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote:
> On Fri, Nov 03, 2017 at 07:26:35PM +0000, Mark Rutland wrote:
> > I guess that in Google you haven't tested on a platform with EL2
> > available?
> 
> Correct. I'll look into this and include a fix in v2. Does this work on a
> clang build without LTO?

I saw this on v4.14-rc7, with patch 7 (-mno-implicit-float), but no other
patches from this series (i.e. no LTO).

Thanks,
Mark.

Re: [PATCH 00/15] Add support for clang LTO

[AKASHI Takahiro]

On Sat, Nov 04, 2017 at 02:13:04AM +0000, Mark Rutland wrote:
> On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote:
> > On Fri, Nov 03, 2017 at 07:26:35PM +0000, Mark Rutland wrote:
> > > I guess that in Google you haven't tested on a platform with EL2
> > > available?
> > 
> > Correct. I'll look into this and include a fix in v2. Does this work on a
> > clang build without LTO?
> 
> I saw this on v4.14-rc7, with patch 7 (-mno-implicit-float), but no other
> patches from this series (i.e. no LTO).


Add -fno-jump-tables to ccflags-y of arch/arm64/kvm/hyp/Makefile.
Without this option, clang generates a branch instruction (br x11)
to an absolute (EL1) virtual address.

-Takahiro AKASHI

> Thanks,
> Mark.

Re: [PATCH 00/15] Add support for clang LTO

[Marc Zyngier]

On 09/11/17 10:54, AKASHI Takahiro wrote:
> On Sat, Nov 04, 2017 at 02:13:04AM +0000, Mark Rutland wrote:
>> On Fri, Nov 03, 2017 at 12:56:47PM -0700, Sami Tolvanen wrote:
>>> On Fri, Nov 03, 2017 at 07:26:35PM +0000, Mark Rutland wrote:
>>>> I guess that in Google you haven't tested on a platform with EL2
>>>> available?
>>>
>>> Correct. I'll look into this and include a fix in v2. Does this work on a
>>> clang build without LTO?
>>
>> I saw this on v4.14-rc7, with patch 7 (-mno-implicit-float), but no other
>> patches from this series (i.e. no LTO).
> 
> 
> Add -fno-jump-tables to ccflags-y of arch/arm64/kvm/hyp/Makefile.
> Without this option, clang generates a branch instruction (br x11)
> to an absolute (EL1) virtual address.

Instead of adding more compiler flags to the Makefile, is there any way
to have that as a function attribute?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 00/15] Add support for clang LTO

[Sami Tolvanen]

On Thu, Nov 09, 2017 at 07:54:40PM +0900, AKASHI Takahiro wrote:
> Add -fno-jump-tables to ccflags-y of arch/arm64/kvm/hyp/Makefile.
> Without this option, clang generates a branch instruction (br x11)
> to an absolute (EL1) virtual address.

Yes, the behavior changed in LLVM r308050, which is part of the 5.0
release, but not in the latest Android clang prebuilts. Before this
change, no branches were generated in __init_stage2_translation.

Using -mllvm -jump-threading-threshold=0 also appears to solve this
problem.

Sami

Re: [PATCH 00/15] Add support for clang LTO

[Ard Biesheuvel]

On 3 November 2017 at 19:26, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Nov 03, 2017 at 11:11:45AM -0700, Nick Desaulniers wrote:
>> On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> ently compile
>> > What's the minimum set of patches necessary to work with clang (ignoring
>> > LTO)?
>>
>> If you have a build of clang-5, then just patch 7 in this series to
>> work around the last compiler bug.  If you build clang from source
>> from master, ToT, for arm64, then none. :)
>
> Thanks for the pointers.
>
> With patch 7 I can build a defconfig from the arm64 for-next/core
> branch, but it panics (in hyp) on my Juno R1 when initialising hyp.
>
> If I build that branch with the Linaro 17.05 GCC 6.3.1 toolchain, I get
> all the way to userspace.
>
> The same is true (for both compilers) with v4.14-rc7.
>
> I guess that in Google you haven't tested on a platform with EL2
> available?
>
> [    1.301280] kvm [1]: 8-bit VMID
> [    1.304416] kvm [1]: IDMAP page: 809e2000
> [    1.308406] kvm [1]: HYP VA range: 800000000000:ffffffffffff
> [    1.315077] kvm [1]: Hyp mode initialized successfully
> [    1.320211] Kernel panic - not syncing: HYP panic:
> [    1.320211] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> [    1.320211] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> [    1.320211] VCPU:000804fc20001221
> [    1.320211]
> [    1.341947] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc7-dirty #3
> [    1.348675] Hardware name: ARM Juno development board (r1) (DT)
> [    1.354543] Call trace:
> [    1.356977] [<ffff000008088ea4>] dump_backtrace+0x0/0x34c
> [    1.362333] [<ffff000008089208>] show_stack+0x18/0x20
> [    1.367345] [<ffff0000089c73ec>] dump_stack+0xc4/0xfc
> [    1.372357] [<ffff0000080c8e1c>] panic+0x138/0x2b4
> [    1.377109] [<ffff0000080c8ce4>] panic+0x0/0x2b4
> [    1.381692] SMP: stopping secondary CPUs
> [    2.571295] SMP: failed to stop secondary CPUs 0-3,5
> [    2.576214] Kernel Offset: disabled
> [    2.579670] CPU features: 0x002086
> [    2.583039] Memory Limit: none
> [    2.586073] ---[ end Kernel panic - not syncing: HYP panic:
> [    2.586073] PS:800003c9 PC:ffff0000089e6fd8 ESR:86000004
> [    2.586073] FAR:ffff0000089e6fd8 HPFAR:0000000009825000 PAR:0000000000000000
> [    2.586073] VCPU:000804fc20001221
>
> The PC in question is:
>
> [mark@lakrids:~/src/linux]% uselinaro 17.05 aarch64-linux-gnu-addr2line -ife vmlinux ffff0000089e6fd8
> __init_stage2_translation
> /home/mark/src/linux/arch/arm64/kvm/hyp/s2-setup.c:38
>
> AFAICT, the generated assembly is only using PC-relative branches, and
> no absolute relocations:
>
> 0000000000000000 <__init_stage2_translation>:
>    0:   d5380709        mrs     x9, id_aa64mmfr0_el1
>    4:   12000928        and     w8, w9, #0x7
>    8:   7100111f        cmp     w8, #0x4
>    c:   d3700928        ubfiz   x8, x9, #16, #3
>   10:   54000188        b.hi    40 <__init_stage2_translation+0x40>
>   14:   9000000a        adrp    x10, 0 <__init_stage2_translation>
>   18:   92400929        and     x9, x9, #0x7
>   1c:   9100014a        add     x10, x10, #0x0
>   20:   f869794b        ldr     x11, [x10,x9,lsl #3]
>   24:   52800509        mov     w9, #0x28                       // #40
>   28:   321b03e0        orr     w0, wzr, #0x20
>   2c:   321b03ea        orr     w10, wzr, #0x20
>   30:   d61f0160        br      x11
>   34:   52800480        mov     w0, #0x24                       // #36
>   38:   321e0bea        orr     w10, wzr, #0x1c
>   3c:   14000008        b       5c <__init_stage2_translation+0x5c>
>   40:   321c07e9        orr     w9, wzr, #0x30
>   44:   14000004        b       54 <__init_stage2_translation+0x54>
>   48:   52800549        mov     w9, #0x2a                       // #42
>   4c:   14000002        b       54 <__init_stage2_translation+0x54>
>   50:   52800589        mov     w9, #0x2c                       // #44
>   54:   321d07ea        orr     w10, wzr, #0x18
>   58:   2a0903e0        mov     w0, w9
>   5c:   aa080148        orr     x8, x10, x8
>   60:   929957ea        mov     x10, #0xffffffffffff3540        // #-51904
>   64:   d5380729        mrs     x9, id_aa64mmfr1_el1
>   68:   f2b0000a        movk    x10, #0x8000, lsl #16
>   6c:   d538072b        mrs     x11, id_aa64mmfr1_el1
>   70:   9148014c        add     x12, x10, #0x200, lsl #12
>   74:   f2400d3f        tst     x9, #0xf
>   78:   927c0d69        and     x9, x11, #0xf0
>   7c:   9a8c014a        csel    x10, x10, x12, eq
>   80:   f100813f        cmp     x9, #0x20
>   84:   aa0a0108        orr     x8, x8, x10
>   88:   1a9f17e9        cset    w9, eq
>   8c:   aa094d08        orr     x8, x8, x9, lsl #19
>   90:   d51c2148        msr     vtcr_el2, x8
>   94:   d65f03c0        ret
>
> ... so I guess something is going wrong around kvm_call_hyp() where this
> is called from EL1.
>

Given that PC == FAR here, it seems kvm_call_hyp() is calling this
function at its EL1 virtual address, so I suspect the VHE alternatives
patching is miscompiled here.

Re: [PATCH 00/15] Add support for clang LTO

[Sami Tolvanen]

On Fri, Nov 03, 2017 at 05:51:56PM +0000, Mark Rutland wrote:
> Which tree are you testing with?

I've tested that this builds on top of Linus' current tree.

> I had to create an aarch64-linux-gnu-clang wrapper, too. I'm not sure if
> there's build system help to avoid needing that?

This appears to depend on how your toolchain was built as Nick mentioned in
an earlier message. I compiled clang from the unified LLVM git repo using
this configuration:

  $ make -G Ninja ../llvm-project/llvm \
	-DCMAKE_BUILD_TYPE=Release \
	-DENABLE_PIC=1 \
	-DLLVM_BINUTILS_INCDIR=/path/to/binutils-2.27/include \
	-DLLVM_TARGETS_TO_BUILD="X86;AArch64" && \
    ninja

Sami