On Thu, Nov 30, 2017 at 09:21:49PM +0900, Masahiro Yamada wrote:
> BTW, did this patch work in your test?
Yes, but it looks like /bin/sh is symlinked to bash on my system. I can
reproduce the issue with dash.
> As for the macro names, maybe
>
> __cc-ifversion, __cc-if-fullversion for
On Thu, Nov 30, 2017 at 09:21:49PM +0900, Masahiro Yamada wrote:
> BTW, did this patch work in your test?
Yes, but it looks like /bin/sh is symlinked to bash on my system. I can
reproduce the issue with dash.
> As for the macro names, maybe
>
> __cc-ifversion, __cc-if-fullversion for
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec
instead of aarch64linux.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
Acked-by: Yury Norov <yno...@caviumnetworks.com>
---
arch/arm64/Makefile | 8
1 file changed, 8 insertions(+)
diff --git
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 <samitolva...@google.com>
Reviewed-by: Nick Desaulniers <ndesaulni...@google.com>
---
Makefile
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec
instead of aarch64linux.
Signed-off-by: Sami Tolvanen
Acked-by: Yury Norov
---
arch/arm64/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b35788c909f1
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
Reviewed-by: Nick Desaulniers
---
Makefile | 5 +
scripts/Kbuild.include | 4
2 files changed
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 <samitolva...@google.com>
---
include/asm-generic/vmlinux.lds.h | 8
1 file changed, 4 insertions
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
---
include/asm-generic/vmlinux.lds.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
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 <samitolva...@google.com>
---
arch/arm64/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
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
---
arch/arm64/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel
the erratum
fix is not used even if the linker is configured to enable it by
default.
This change also adds a warning if the erratum fix is enabled and
gold version <1.14 is used.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Makefile | 9 +
1 file changed, 9 i
the erratum
fix is not used even if the linker is configured to enable it by
default.
This change also adds a warning if the erratum fix is enabled and
gold version <1.14 is used.
Signed-off-by: Sami Tolvanen
---
arch/arm64/Makefile | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/ar
Add macros for testing both linker name and version.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
scripts/Kbuild.include | 12
1 file changed, 12 insertions(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index a7c7843c2cf1..5d286d69e8dc
All current versions of GNU gold crash when linking kernel modules
with ARM64_MODULE_PLTS due to a known bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14592
To work around the problem, this change removes NOLOAD from .plt
and .init.plt.
Signed-off-by: Sami Tolvanen <samito
Add macros for testing both linker name and version.
Signed-off-by: Sami Tolvanen
---
scripts/Kbuild.include | 12
1 file changed, 12 insertions(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index a7c7843c2cf1..5d286d69e8dc 100644
--- a/scripts/Kbuild.include
All current versions of GNU gold crash when linking kernel modules
with ARM64_MODULE_PLTS due to a known bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14592
To work around the problem, this change removes NOLOAD from .plt
and .init.plt.
Signed-off-by: Sami Tolvanen
---
arch/arm64
These patches add macros for detecting the linker name and version,
and apply fixes and workarounds needed to link the arm64 kernel with
GNU gold.
Sami Tolvanen (7):
kbuild: add ld-name macro and support for GNU gold
kbuild: add ld-if-name-version and linker-specific macros
kbuild: fix
These patches add macros for detecting the linker name and version,
and apply fixes and workarounds needed to link the arm64 kernel with
GNU gold.
Sami Tolvanen (7):
kbuild: add ld-name macro and support for GNU gold
kbuild: add ld-if-name-version and linker-specific macros
kbuild: fix
On Tue, Nov 21, 2017 at 11:01:52AM +1000, Nicholas Piggin wrote:
> I just wonder are you doing this because there is some worthwhile
> performance gain? Or to enable more testing and development of LTO?
> Any clues for why a user would want to enable it.
I'm primarily interested in CFI, which
On Tue, Nov 21, 2017 at 11:01:52AM +1000, Nicholas Piggin wrote:
> I just wonder are you doing this because there is some worthwhile
> performance gain? Or to enable more testing and development of LTO?
> Any clues for why a user would want to enable it.
I'm primarily interested in CFI, which
Hi Andi,
On Mon, Nov 27, 2017 at 01:34:02PM -0800, Andi Kleen wrote:
> This is an updated version of my older LTO patchkit for gcc/x86
> This version doesn't need special binutils, but requires gcc 5+.
> It also is compatible with near all options (except MODVERSIONS)
Would you mind changing the
Hi Andi,
On Mon, Nov 27, 2017 at 01:34:02PM -0800, Andi Kleen wrote:
> This is an updated version of my older LTO patchkit for gcc/x86
> This version doesn't need special binutils, but requires gcc 5+.
> It also is compatible with near all options (except MODVERSIONS)
Would you mind changing the
On Wed, Nov 29, 2017 at 12:15:14PM +, Ard Biesheuvel wrote:
> Do we still need these patches now that the AES code has been fixed?
With your AES patch that Herbert just applied, this patch is no longer
needed. Version macros in the first two patches will still be useful in
future though.
On Wed, Nov 29, 2017 at 12:15:14PM +, Ard Biesheuvel wrote:
> Do we still need these patches now that the AES code has been fixed?
With your AES patch that Herbert just applied, this patch is no longer
needed. Version macros in the first two patches will still be useful in
future though.
Cc: Matthias Kaehlcke <m...@chromium.org>
[added clang-ifversion to enable the workaround only for clang <6.0]
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile
the workaround only for clang <6.0]
Signed-off-by: Sami Tolvanen
---
arch/arm64/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b35788c909f1..d2efb5a0212f 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makef
Based on gcc-version.sh, clang-version.sh prints out the correct
version of clang.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
scripts/clang-version.sh | 33 +
1 file changed, 33 insertions(+)
create mode 100755 scripts/clang-version.sh
diff
Based on gcc-version.sh, clang-version.sh prints out the correct
version of clang.
Signed-off-by: Sami Tolvanen
---
scripts/clang-version.sh | 33 +
1 file changed, 33 insertions(+)
create mode 100755 scripts/clang-version.sh
diff --git a/scripts/clang
This change adds macros for testing both compiler name and
version. Current cc-version, cc-ifversion etc. macros that test
gcc version are left unchanged to prevent compatibility issues
with existing tests.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
scripts/Kbuild.includ
This change adds macros for testing both compiler name and
version. Current cc-version, cc-ifversion etc. macros that test
gcc version are left unchanged to prevent compatibility issues
with existing tests.
Signed-off-by: Sami Tolvanen
---
scripts/Kbuild.include | 31
m64: use -mno-implicit-float instead of -mgeneral-regs-only
Sami Tolvanen (2):
kbuild: add clang-version.sh
kbuild: add cc-if-name-version and compiler-specific variants
arch/arm64/Makefile | 5 -
scripts/Kbuild.include | 31 +++
scripts/clang-version
m64: use -mno-implicit-float instead of -mgeneral-regs-only
Sami Tolvanen (2):
kbuild: add clang-version.sh
kbuild: add cc-if-name-version and compiler-specific variants
arch/arm64/Makefile | 5 -
scripts/Kbuild.include | 31 +++
scripts/clang-version
On Mon, Nov 20, 2017 at 03:21:40PM +, Mark Rutland wrote:
> Would it be possible to split this into:
>
> (1) (basic) arm64 clang support
> (2) gold support (no LTO)
> (3) LTO support
>
> ... with any necessary workarounds added as-required to the relevant
> series?
Absolutely. I'll split
On Mon, Nov 20, 2017 at 03:21:40PM +, Mark Rutland wrote:
> Would it be possible to split this into:
>
> (1) (basic) arm64 clang support
> (2) gold support (no LTO)
> (3) LTO support
>
> ... with any necessary workarounds added as-required to the relevant
> series?
Absolutely. I'll split
On Mon, Nov 20, 2017 at 03:25:31PM +, Ard Biesheuvel wrote:
> However, under LTO this all changes, and it is no longer guaranteed
> that the NEON registers are only touched between the kernel mode
> neon begin/end calls.
LTO operates on LLVM IR, so disabling LTO for this file should make
sure
On Mon, Nov 20, 2017 at 03:25:31PM +, Ard Biesheuvel wrote:
> However, under LTO this all changes, and it is no longer guaranteed
> that the NEON registers are only touched between the kernel mode
> neon begin/end calls.
LTO operates on LLVM IR, so disabling LTO for this file should make
sure
On Mon, Nov 20, 2017 at 03:20:14PM +, Mark Rutland wrote:
> Could you elaborate on what the integrated asembler doesn't like?
Here's the error, looks like in aes_sub:
:1:69: error: invalid operand for instruction
dup v1.4s, w12 ;movi v0.16b, #0 ;aese
On Mon, Nov 20, 2017 at 03:20:14PM +, Mark Rutland wrote:
> Could you elaborate on what the integrated asembler doesn't like?
Here's the error, looks like in aes_sub:
:1:69: error: invalid operand for instruction
dup v1.4s, w12 ;movi v0.16b, #0 ;aese
On Mon, Nov 20, 2017 at 02:47:20PM +, Mark Rutland wrote:
> However, we could instead check ld-version, produce a warning, and
> abort the build in such cases.
I believe the version number of gold didn't change in binutils 2.28.1,
where this was fixed, but we could certainly warn about older
On Mon, Nov 20, 2017 at 02:47:20PM +, Mark Rutland wrote:
> However, we could instead check ld-version, produce a warning, and
> abort the build in such cases.
I believe the version number of gold didn't change in binutils 2.28.1,
where this was fixed, but we could certainly warn about older
On Sat, Nov 18, 2017 at 01:21:39PM +1000, Nicholas Piggin wrote:
> Do you have any kind of numbers for this, out of curiosity? Binary
> size, performance, build time?
I don't have performance numbers to share. Are there any specific
benchmarks you'd be interested in seeing? Build time typically
On Sat, Nov 18, 2017 at 01:21:39PM +1000, Nicholas Piggin wrote:
> Do you have any kind of numbers for this, out of curiosity? Binary
> size, performance, build time?
I don't have performance numbers to share. Are there any specific
benchmarks you'd be interested in seeing? Build time typically
On Fri, Nov 17, 2017 at 09:54:48AM +, Ard Biesheuvel wrote:
> OK, so all IR objects are converted into a single .o file
> encapsulating the module image. Does this give the same benefits as
> LTO linking IR objects to a fully linked executable?
Yes, it does.
> Even if it does, partial
On Fri, Nov 17, 2017 at 09:54:48AM +, Ard Biesheuvel wrote:
> OK, so all IR objects are converted into a single .o file
> encapsulating the module image. Does this give the same benefits as
> LTO linking IR objects to a fully linked executable?
Yes, it does.
> Even if it does, partial
On Thu, Nov 16, 2017 at 11:20:40PM +, Ard Biesheuvel wrote:
> So at which point is the IR in a partially linked object file
> converted into executable code?
At the final module link step (cmd_ld_ko_o) in scripts/Makefile.modpost,
added in patch 12.
Sami
On Thu, Nov 16, 2017 at 11:20:40PM +, Ard Biesheuvel wrote:
> So at which point is the IR in a partially linked object file
> converted into executable code?
At the final module link step (cmd_ld_ko_o) in scripts/Makefile.modpost,
added in patch 12.
Sami
On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote:
> OK, so my concern here is that this code probably only operates on
> fully linked binaries, and not partially linked object files like
> kernel modules.
Right. That makes sense.
> What is preventing us from using the large model
On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote:
> OK, so my concern here is that this code probably only operates on
> fully linked binaries, and not partially linked object files like
> kernel modules.
Right. That makes sense.
> What is preventing us from using the large model
On Thu, Nov 16, 2017 at 11:53:00PM +0300, Yury Norov wrote:
> I would suggest you to add the patch that checks their versions and
> disables LTO if needed.
Sure, sounds reasonable. I'll add this in the next version.
Sami
On Thu, Nov 16, 2017 at 11:53:00PM +0300, Yury Norov wrote:
> I would suggest you to add the patch that checks their versions and
> disables LTO if needed.
Sure, sounds reasonable. I'll add this in the next version.
Sami
On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote:
> You still have not explained to us how GOLD avoids the erratum.
Sorry, I didn't realize you were asking that. If gold spots erratum
sequences, looks like it creates stubs to break them up:
On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote:
> You still have not explained to us how GOLD avoids the erratum.
Sorry, I didn't realize you were asking that. If gold spots erratum
sequences, looks like it creates stubs to break them up:
On Thu, Nov 16, 2017 at 11:13:07AM -0800, Paul E. McKenney wrote:
> Ah, if "this patch set" meant "adding LTO", I stand corrected and I
> apologize for my confusion.
Again, I'm not proposing for LTO to be enabled by default. These patches
just make it possible to enable it. Are you saying the
On Thu, Nov 16, 2017 at 11:13:07AM -0800, Paul E. McKenney wrote:
> Ah, if "this patch set" meant "adding LTO", I stand corrected and I
> apologize for my confusion.
Again, I'm not proposing for LTO to be enabled by default. These patches
just make it possible to enable it. Are you saying the
On Thu, Nov 16, 2017 at 11:01:44AM -0600, Segher Boessenkool wrote:
> The thing with .purgem can work. Inelegant, sure, but it can work :-)
It works, there are already functions in the kernel that use these
macros more than once. I agree that this might not be the most elegant
solution, but at
On Thu, Nov 16, 2017 at 11:01:44AM -0600, Segher Boessenkool wrote:
> The thing with .purgem can work. Inelegant, sure, but it can work :-)
It works, there are already functions in the kernel that use these
macros more than once. I agree that this might not be the most elegant
solution, but at
On Thu, Nov 16, 2017 at 07:56:50AM -0600, Segher Boessenkool wrote:
> The compiler is fine, the assembler is fine (and the linker has
> nothing to do with it). Your code is not fine.
Would you care to elaborate? The current code assumes that macros are
visible in other inline assembly blocks,
On Thu, Nov 16, 2017 at 07:56:50AM -0600, Segher Boessenkool wrote:
> The compiler is fine, the assembler is fine (and the linker has
> nothing to do with it). Your code is not fine.
Would you care to elaborate? The current code assumes that macros are
visible in other inline assembly blocks,
On Thu, Nov 16, 2017 at 11:54:33AM +, Will Deacon wrote:
> What limitations? Can you elaborate please? Is this a fix?
The commit message in v1 was more informative, I'll change this back for v3:
--
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block
On Thu, Nov 16, 2017 at 11:54:33AM +, Will Deacon wrote:
> What limitations? Can you elaborate please? Is this a fix?
The commit message in v1 was more informative, I'll change this back for v3:
--
Clang's integrated assembler does not allow assembly macros defined
in one inline asm block
On Thu, Nov 16, 2017 at 11:50:12AM +, Will Deacon wrote:
> Why don't we just not do LTO if the toolchain is busted?
Because LTO can not only potentially improve performance, especially
when combined with PGO (Profile Guided Optimization), but it also
makes it possible to enable features like
On Thu, Nov 16, 2017 at 11:50:12AM +, Will Deacon wrote:
> Why don't we just not do LTO if the toolchain is busted?
Because LTO can not only potentially improve performance, especially
when combined with PGO (Profile Guided Optimization), but it also
makes it possible to enable features like
On Thu, Nov 16, 2017 at 11:47:23AM +, Will Deacon wrote:
> But if ARM64_ERRATUM_843419 is enabled, we'll go ahead and generate
> broken code?
This bug has been fixed in all current versions of GNU gold, but of
course, if someone is using a broken linker, it will generate broken
code. We can't
On Thu, Nov 16, 2017 at 11:47:23AM +, Will Deacon wrote:
> But if ARM64_ERRATUM_843419 is enabled, we'll go ahead and generate
> broken code?
This bug has been fixed in all current versions of GNU gold, but of
course, if someone is using a broken linker, it will generate broken
code. We can't
On Thu, Nov 16, 2017 at 11:44:06AM +, Will Deacon wrote:
> Right, and this would also mean that we silently load vulnerable
> modules that are linked with either LD that doesn't support
> --fix-cortex-a53-843419 or simply wasn't passed.
You'll see a warning at least if the linker doesn't
On Thu, Nov 16, 2017 at 11:44:06AM +, Will Deacon wrote:
> Right, and this would also mean that we silently load vulnerable
> modules that are linked with either LD that doesn't support
> --fix-cortex-a53-843419 or simply wasn't passed.
You'll see a warning at least if the linker doesn't
On Thu, Nov 16, 2017 at 11:46:17AM +, Will Deacon wrote:
> Can you elaborate a bit more on exactly what you saw failing here,
> please?
Mark noticed that clang built kernels fail to boot when the kernel
starts at EL2:
http://lkml.iu.edu/hypermail/linux/kernel/1711.0/02817.html
Turns out
On Thu, Nov 16, 2017 at 11:46:17AM +, Will Deacon wrote:
> Can you elaborate a bit more on exactly what you saw failing here,
> please?
Mark noticed that clang built kernels fail to boot when the kernel
starts at EL2:
http://lkml.iu.edu/hypermail/linux/kernel/1711.0/02817.html
Turns out
On Thu, Nov 16, 2017 at 11:58:11AM +, Will Deacon wrote:
> I'll be honest with you: I'm absolutely terrified about enabling this.
That's understandable, I wouldn't want to enable this by default
quite yet either. This patch doesn't enable LTO for arm64, just makes
it possible to enable the
On Thu, Nov 16, 2017 at 11:58:11AM +, Will Deacon wrote:
> I'll be honest with you: I'm absolutely terrified about enabling this.
That's understandable, I wouldn't want to enable this by default
quite yet either. This patch doesn't enable LTO for arm64, just makes
it possible to enable the
On Wed, Nov 15, 2017 at 01:48:52PM -0800, Kees Cook wrote:
> It might make sense to split this patch: do the move and refactoring,
> then add clang support.
Sure.
> Though, won't this confuse some tests? A lot of cc-version tests are
> expecting only gcc, yes?
There's already a chance of this
On Wed, Nov 15, 2017 at 01:48:52PM -0800, Kees Cook wrote:
> It might make sense to split this patch: do the move and refactoring,
> then add clang support.
Sure.
> Though, won't this confuse some tests? A lot of cc-version tests are
> expecting only gcc, yes?
There's already a chance of this
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
scripts/Kbuild.include | 4 ++--
scripts/cc-version.sh | 45 +
scripts/gcc-version.sh | 33 -
3 files changed, 47 insertions(+), 35 deletions(-)
creat
Signed-off-by: Sami Tolvanen
---
scripts/Kbuild.include | 4 ++--
scripts/cc-version.sh | 45 +
scripts/gcc-version.sh | 33 -
3 files changed, 47 insertions(+), 35 deletions(-)
create mode 100755 scripts/cc
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec
instead of aarch64linux.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
Cc: Matthias Kaehlcke <m...@chromium.org>
[added cc-ifversion to enable the workaround only for clang <6.0]
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile
GNU gold supports different emulations than bfd. Use aarch64_elf64_*_vec
instead of aarch64linux.
Signed-off-by: Sami Tolvanen
---
arch/arm64/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index ecd5ed11c764..6059c8169513 100644
the workaround only for clang <6.0]
Signed-off-by: Sami Tolvanen
---
arch/arm64/Makefile | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b35788c909f1..ecd5ed11c764 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makef
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 <samitolva...@google.com>
---
arch/arm64/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
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
---
arch/arm64/kernel/vmlinux.lds.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel
the erratum fix is not
used even if the linker is configured to enable it by default.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 6059c8169513..ca700b201736
CONFIG_LTO_CLANG depends on GNU gold, which can generate ADR_PREL_PG_HI21*
relocations even with --fix-cortex-a53-843419.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/kernel/module.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/kernel/module.c
the erratum fix is not
used even if the linker is configured to enable it by default.
Signed-off-by: Sami Tolvanen
---
arch/arm64/Makefile | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 6059c8169513..ca700b201736 100644
--- a/arch/arm64/Makefile
CONFIG_LTO_CLANG depends on GNU gold, which can generate ADR_PREL_PG_HI21*
relocations even with --fix-cortex-a53-843419.
Signed-off-by: Sami Tolvanen
---
arch/arm64/kernel/module.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
y Norov <yno...@caviumnetworks.com>
Signed-off-by: Sami Tolvanen <samitolva...@google.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
RANDOMIZE_MODULE_REGION_FULL results in "overflow in relocation type 275"
when loading a module linked with GNU gold. As a workaround, disable when
LTO_CLANG is selected.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1
From: Alex Matveev
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
Signed-off-by: Yury Norov
Signed-off-by: Sami Tolvanen
---
arch/arm64
RANDOMIZE_MODULE_REGION_FULL results in "overflow in relocation type 275"
when loading a module linked with GNU gold. As a workaround, disable when
LTO_CLANG is selected.
Signed-off-by: Sami Tolvanen
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/kernel/module.lds | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
index f7c9781a9d48..eacb5c67f61e 100644
--- a/arch/arm64/kernel/modu
.
Signed-off-by: Sami Tolvanen
---
arch/arm64/kernel/module.lds | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
index f7c9781a9d48..eacb5c67f61e 100644
--- a/arch/arm64/kernel/module.lds
+++ b/arch/arm64/kernel
Allow CONFIG_LTO_CLANG to be enabled for the architecture.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3a70f763e18a..58504327b9f6 100644
--- a/arch/arm64/K
Allow CONFIG_LTO_CLANG to be enabled for the architecture.
Signed-off-by: Sami Tolvanen
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3a70f763e18a..58504327b9f6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
is in LD_LIBRARY_PATH and CONFIG_LTO_CLANG has
been selected, an LTO kernel can be built simply by running make
CC=clang. Recommended versions are >= 5.0 for clang, and >= 2.27 for
binutils.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
.gitignore | 2
is in LD_LIBRARY_PATH and CONFIG_LTO_CLANG has
been selected, an LTO kernel can be built simply by running make
CC=clang. Recommended versions are >= 5.0 for clang, and >= 2.27 for
binutils.
Signed-off-by: Sami Tolvanen
---
.gitignore | 2 ++
Makefile
With CONFIG_LTO_CLANG, 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 <samitolva...@google.com>
---
scripts/mod/Makefile | 1 +
1 file changed, 1 ins
With CONFIG_LTO_CLANG, 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
---
scripts/mod/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts
, and
a __norecordmcount attribute for moving functions to this section.
Signed-off-by: Sami Tolvanen <samitolva...@google.com>
---
arch/Kconfig | 2 +-
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/compiler-clang.h| 7 +++
include/linux/compiler_t
, and
a __norecordmcount attribute for moving functions to this section.
Signed-off-by: Sami Tolvanen
---
arch/Kconfig | 2 +-
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/compiler-clang.h| 7 +++
include/linux/compiler_types.h| 4
kernel/trace
CONFIG_LTO_CLANG 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.
Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: Sami Tolvanen <samitolva...@g
CONFIG_LTO_CLANG 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.
Acked-by: Ard Biesheuvel
Signed-off-by: Sami Tolvanen
---
arch/arm64/crypto/Makefile | 2 +-
1 file changed, 1
701 - 800 of 912 matches
Mail list logo
