arm64: jump_label: use constraints "Si" instead of "i"
Subsystems (2)
PATCH v2 1/1 arm64: jump_label: use constraints "Si" instead of "i"
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g. static_key_false(&nf_hooks_needed[pf][hook]) in include/linux/netfilter.h), so we use "i" as a fallback.
---
Changes from
arm64: jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operand
Changes from v1:
* Use asmSymbolicName for readability
--- arch/arm64/include/asm/jump_label.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
arch/arm64/include/asm/jump_label.h +8 -4
@@ -15,6 +15,10 @@#define JUMP_LABEL_NOP_SIZE AARCH64_INSN_SIZE +/* +* Prefer the constraint "S" to support PIC with GCC. Clang before 19 does not +* support "S" on a symbol with a constant offset, so we use "i" as a fallback. +*/ static __always_inline bool arch_static_branch(struct static_key * const key,const bool branch) {
@@ -23,9 +27,9 @@ static __always_inline bool arch_static_branch(struct static_key * const key," .pushsection __jump_table, \"aw\" \n\t" " .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:
@@ -40,9 +44,9 @@ static __always_inline bool arch_static_branch_jump(struct static_key * const ke" .pushsection __jump_table, \"aw\" \n\t" " .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:
Signature · 1 line
2.43.0.594.gd9cf4e227d-goog
Quoted 11 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.
Quoted 3 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>
This looks reasonable to me, and works with the toolchains I've tried, so:
Mark.
Quoted 57 lines
---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
--- arch/arm64/include/asm/jump_label.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)arch/arm64/include/asm/jump_label.h +8
-4@@ -15,6 +15,10 @@#define JUMP_LABEL_NOP_SIZE AARCH64_INSN_SIZE +/* +* Prefer the constraint "S" to support PIC with GCC. Clang before 19 does not +* support "S" on a symbol with a constant offset, so we use "i" as a fallback. +*/ static __always_inline bool arch_static_branch(struct static_key * const key,const bool branch) {@@ -23,9 +27,9 @@ static __always_inline bool arch_static_branch(struct static_key * const key," .pushsection __jump_table, \"aw\" \n\t" " .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:@@ -40,9 +44,9 @@ static __always_inline bool arch_static_branch_jump(struct static_key * const ke" .pushsection __jump_table, \"aw\" \n\t" " .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:Signature · 1 line
2.43.0.594.gd9cf4e227d-goog
Quoted 4 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Quoted 8 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.[...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: jump_label: use constraints "Si" instead of "i"
https://git.kernel.org/arm64/c/f9daab0ad01c
Cheers,
Signature · 5 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Hi Fangrui,
Quoted 3 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Thanks for your patch, which is now commit f9daab0ad01cf9d1 ("arm64:jump_label: use constraints "Si" instead of "i"") in v6.8-rc5.
Quoted 6 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.
https://gcc.gnu.org/releases.html says gcc-5 was released in 2015, i.e. after 2012 ...
Quoted 8 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)
Quoted 6 lines
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm':
invalid operand
asm goto(
^http://kisskb.ellerman.id.au/kisskb/buildresult/15129281/
Quoted 27 lines
arch/arm64/include/asm/jump_label.h +6
-2@@ -15,6 +15,10 @@#define JUMP_LABEL_NOP_SIZE AARCH64_INSN_SIZE +/* +* Prefer the constraint "S" to support PIC with GCC. Clang before 19 does not +* support "S" on a symbol with a constant offset, so we use "i" as a fallback. +*/ static __always_inline bool arch_static_branch(struct static_key * const key,const bool branch) {@@ -23,9 +27,9 @@ static __always_inline bool arch_static_branch(struct static_key * const key," .pushsection __jump_table, \"aw\" \n\t" " .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:@@ -40,9 +44,9 @@ static __always_inline bool arch_static_branch_jump(struct static_key * const ke" .pushsection __jump_table, \"aw\" \n\t"
arch/arm64/include/asm/jump_label.h static __always_inline bool arch_static_branch_jump(struct static_key * const ke · line 52
Quoted 10 lines
arch/arm64/include/asm/jump_label.h +2
-2" .align 3 \n\t" " .long 1b - ., %l[l_yes] - . \n\t" - " .quad %c0 - . \n\t" +" .quad (%[key] - .) + %[bit0] \n\t" " .popsection \n\t" - : : "i"(&((char *)key)[branch]) : : l_yes); + : : [key]"Si"(key), [bit0]"i"(branch) : : l_yes);return false; l_yes:
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Ard Biesheuvel
reviewerQuoted 36 lines · Geert Uytterhoeven
Hi Fangrui,
Quoted 3 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Thanks for your patch, which is now commit
f9daab0ad01cf9d1("arm64:jump_label: use constraints "Si" instead of "i"") in v6.8-rc5.Quoted 6 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.https://gcc.gnu.org/releases.html says gcc-5 was released in 2015, i.e. after 2012 ...
Quoted 8 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)Quoted 6 lines
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
Quoted 9 lines
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': invalid operand asm goto( ^
How odd. godbolt.org has 5.4 and it seems perfectly happy with it.
Ard Biesheuvel
reviewerQuoted 45 lines · Ard Biesheuvel
Quoted 43 lines · Geert Uytterhoeven
Hi Fangrui,
Quoted 3 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Thanks for your patch, which is now commit
f9daab0ad01cf9d1("arm64:jump_label: use constraints "Si" instead of "i"") in v6.8-rc5.Quoted 6 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.https://gcc.gnu.org/releases.html says gcc-5 was released in 2015, i.e. after 2012 ...
Quoted 8 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)Quoted 6 lines
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': invalid operand asm goto( ^
Quoted 6 lines
How odd. godbolt.org has 5.4 and it seems perfectly happy with it.
Wrong link
Hi Ard,
Quoted 42 lines · Ard Biesheuvel
Quoted 41 lines · Ard Biesheuvel
Quoted 40 lines · Geert Uytterhoeven
Quoted 3 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Thanks for your patch, which is now commit
f9daab0ad01cf9d1("arm64:jump_label: use constraints "Si" instead of "i"") in v6.8-rc5.Quoted 6 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.https://gcc.gnu.org/releases.html says gcc-5 was released in 2015, i.e. after 2012 ...
Quoted 8 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)Quoted 6 lines
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': invalid operand asm goto( ^
Quoted 6 lines
Quoted 4 lines
How odd. godbolt.org has 5.4 and it seems perfectly happy with it.
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:
In file included from ./include/linux/jump_label.h:112:0,
from ./include/linux/static_key.h:1,
from ./include/linux/kasan-enabled.h:5,
from ./arch/arm64/include/asm/cache.h:41,
from ./include/linux/cache.h:6,
from ./include/linux/slab.h:15,
from ./include/linux/resource_ext.h:11,
from ./include/linux/acpi.h:13,
from arch/arm64/mm/fault.c:10:
arch/arm64/mm/fault.c: In function 'do_page_fault':
./arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm':
invalid operand
asm goto(
^
./arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm':invalid operand
There are also a few warnings due to unrecognized options:
arch/arm64/mm/fault.c: At top level:
cc1: warning: unrecognized command line option '-Wno-shift-negative-value'
cc1: warning: unrecognized command line option '-Wno-stringop-overflow'
Thanks!
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Ard Biesheuvel
reviewerQuoted 49 lines · Geert Uytterhoeven
Hi Ard,
Quoted 45 lines · Ard Biesheuvel
Quoted 44 lines · Ard Biesheuvel
Quoted 42 lines · Geert Uytterhoeven
Quoted 3 lines · Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port.
Thanks for your patch, which is now commit
f9daab0ad01cf9d1("arm64:jump_label: use constraints "Si" instead of "i"") in v6.8-rc5.Quoted 6 lines
The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g.
static_key_false(&nf_hooks_needed[pf][hook])ininclude/linux/netfilter.h), so we use "i" as a fallback.https://gcc.gnu.org/releases.html says gcc-5 was released in 2015, i.e. after 2012 ...
Quoted 8 lines
Suggested-by Ard Biesheuvel <[email protected]>Signed-off-by Fangrui Song <[email protected]>---
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)Quoted 6 lines
* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': invalid operand asm goto( ^
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
How odd. godbolt.org has 5.4 and it seems perfectly happy with it.
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
Quoted 11 lines · Ard Biesheuvel
Quoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Ard Biesheuvel
On Mon, 19 Feb 2024 at 11:56, Ard Biesheuvel <[email protected]> wrote:
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:
Quoted 7 lines
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
From what I can tell, we may as well formally raise the minimum gcc version to 8.1+ already, as that is a version that is actually used in distros, and we have been on 5.1+ for a few years already.
Not sure if there are any other benefits to gcc-8 besides allowing minor cleanups.
gcc-9 would bring --std=gnu2x support, but it may be too early for that.
Arnd
Mark Rutland
reviewerQuoted 20 lines · Arnd Bergmann
Quoted 11 lines · Ard Biesheuvel
Quoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Ard Biesheuvel
On Mon, 19 Feb 2024 at 11:56, Ard Biesheuvel <[email protected]> wrote:
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:Quoted 7 lines
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
Quoted 7 lines
From what I can tell, we may as well formally raise the minimum gcc version to 8.1+ already, as that is a version that is actually used in distros, and we have been on 5.1+ for a few years already.
Not sure if there are any other benefits to gcc-8 besides allowing minor cleanups.
Arguably a minor cleanup, but on arm64 that'd allow us to get rid of the old mcount-based ftrace implementation and rely on -fpatchable-function-entry. On its own that'd save ~130 lines of asm and ~70 lines of C, but it'd also remove some constraints on other features (e.g. the mcount-based form's graph tracer isn't compatible with pointer authentication), it would simplify a few things going forwards (e.g. the implementation of RELIABLE_STACKTRACE, since we could rely on having ftrace_regs and a single trampoline), and the remaining support would be better tested.
I've wanted to remove the old ftrace implementation for a while, but on its own it was never important/urgent enough to justify bumping to GCC 8+.
Mark.
Ard Biesheuvel
reviewerQuoted 39 lines · Mark Rutland
Quoted 20 lines · Arnd Bergmann
Quoted 11 lines · Ard Biesheuvel
Quoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Ard Biesheuvel
On Mon, 19 Feb 2024 at 11:56, Ard Biesheuvel <[email protected]> wrote:
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:Quoted 7 lines
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
Quoted 7 lines
From what I can tell, we may as well formally raise the minimum gcc version to 8.1+ already, as that is a version that is actually used in distros, and we have been on 5.1+ for a few years already.
Not sure if there are any other benefits to gcc-8 besides allowing minor cleanups.
Arguably a minor cleanup, but on arm64 that'd allow us to get rid of the old mcount-based ftrace implementation and rely on -fpatchable-function-entry. On its own that'd save ~130 lines of asm and ~70 lines of C, but it'd also remove some constraints on other features (e.g. the mcount-based form's graph tracer isn't compatible with pointer authentication), it would simplify a few things going forwards (e.g. the implementation of
RELIABLE_STACKTRACE, since we could rely on havingftrace_regsand a single trampoline), and the remaining support would be better tested.
Quoted 3 lines
I've wanted to remove the old ftrace implementation for a while, but on its own it was never important/urgent enough to justify bumping to GCC 8+.
I don't think this is minor, tbh. Supporting two versions of the highly complex tracing infrastructure for a toolchain that is only used in CI seems like a waste of time and effort.
I checked x86, and it needs at least GCC 7 for retpoline support, so I reckon at least GCC 5/6 support might be dropped there as well.
Ard Biesheuvel
reviewerQuoted 45 lines · Ard Biesheuvel
Quoted 39 lines · Mark Rutland
Quoted 20 lines · Arnd Bergmann
Quoted 11 lines · Ard Biesheuvel
Quoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Ard Biesheuvel
On Mon, 19 Feb 2024 at 11:56, Ard Biesheuvel <[email protected]> wrote:
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:Quoted 7 lines
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
Quoted 7 lines
From what I can tell, we may as well formally raise the minimum gcc version to 8.1+ already, as that is a version that is actually used in distros, and we have been on 5.1+ for a few years already.
Not sure if there are any other benefits to gcc-8 besides allowing minor cleanups.
Arguably a minor cleanup, but on arm64 that'd allow us to get rid of the old mcount-based ftrace implementation and rely on -fpatchable-function-entry. On its own that'd save ~130 lines of asm and ~70 lines of C, but it'd also remove some constraints on other features (e.g. the mcount-based form's graph tracer isn't compatible with pointer authentication), it would simplify a few things going forwards (e.g. the implementation of
RELIABLE_STACKTRACE, since we could rely on havingftrace_regsand a single trampoline), and the remaining support would be better tested.Quoted 3 lines
I've wanted to remove the old ftrace implementation for a while, but on its own it was never important/urgent enough to justify bumping to GCC 8+.
Quoted 6 lines
I don't think this is minor, tbh. Supporting two versions of the highly complex tracing infrastructure for a toolchain that is only used in CI seems like a waste of time and effort.
I checked x86, and it needs at least GCC 7 for retpoline support, so I reckon at least GCC 5/6 support might be dropped there as well.
Another data point: __GCC_ASM_FLAG_OUTPUTS__ needs GCC 6 or later on x86.
Will Deacon
maintainerQuoted 30 lines · Ard Biesheuvel
Quoted 20 lines · Geert Uytterhoeven
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 9 lines
Changes from
arm64:jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/[email protected]/)* Use "Si" as Ard suggested to support Clang<19
* Make branch a separate operandChanges from v1:
* Use asmSymbolicName for readability
But it still fails on gcc-5:
arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm': invalid operand asm goto( ^Quoted 8 lines
Quoted 3 lines
Quoted 1 line
How odd. godbolt.org has 5.4 and it seems perfectly happy with it.
I could reproduce the issue on v6.8-rc5 using arm64 defconfig and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/:
Quoted 7 lines
OK, I managed to do so as well.
And GCC 6.4 from the same source works correctly.
Not sure whether there are any plans to bump the minimal GCC version any time soon (cc'ing Arnd), but we should probably drop this change until that happens.
Yup, makes sense to me. I'll revert the original change and we can bring it back later if we decide to bump the minimum GCC version.
Cheers,
Will