The LLVM Target parser currently does not allow to specify the security
extension as part of -march (see also LLVM Bug 40186 [0]). When trying
to use Clang with LLVM's integrated assembler, this leads to a build
errors such as this:
clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
Use ".arch_extension sec" to enable the security extension in a more
portable fasion.
Note that this is technically not exactly the same as the old code
checked for availabilty of the security extension by calling as-instr.
However, there are already other sites which use ".arch_extension sec"
unconditionally, hence de-facto we need an assembler capable of
".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
arch extension "sec" is available since binutils 2.21 according to
its documentation [1].
[0] https://bugs.llvm.org/show_bug.cgi?id=40186
[1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
Signed-off-by: Stefan Agner <[email protected]>
---
arch/arm/mach-bcm/Makefile | 3 ---
arch/arm/mach-bcm/bcm_kona_smc.c | 2 --
arch/arm/mach-exynos/Makefile | 4 ----
arch/arm/mach-exynos/exynos-smc.S | 2 +-
arch/arm/mach-exynos/sleep.S | 2 +-
arch/arm/mach-highbank/Makefile | 3 ---
arch/arm/mach-highbank/smc.S | 2 +-
arch/arm/mach-keystone/Makefile | 3 ---
arch/arm/mach-keystone/smc.S | 1 +
arch/arm/mach-omap2/Makefile | 8 --------
arch/arm/mach-omap2/omap-headsmp.S | 1 +
arch/arm/mach-omap2/omap-smc.S | 2 +-
arch/arm/mach-omap2/sleep34xx.S | 1 +
arch/arm/mach-omap2/sleep43xx.S | 1 +
arch/arm/mach-omap2/sleep44xx.S | 1 +
arch/arm/mach-tango/Makefile | 3 ---
arch/arm/mach-tango/smc.S | 1 +
17 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 8fd23b263c60..b59c813b1af4 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -40,9 +40,6 @@ obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
# Support for secure monitor traps
obj-$(CONFIG_ARCH_BCM_MOBILE_SMC) += bcm_kona_smc.o
-ifeq ($(call as-instr,.arch_extension sec,as_has_sec),as_has_sec)
-CFLAGS_bcm_kona_smc.o += -Wa,-march=armv7-a+sec -DREQUIRES_SEC
-endif
# BCM2835
obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o
diff --git a/arch/arm/mach-bcm/bcm_kona_smc.c b/arch/arm/mach-bcm/bcm_kona_smc.c
index a55a7ecf146a..541e850a736c 100644
--- a/arch/arm/mach-bcm/bcm_kona_smc.c
+++ b/arch/arm/mach-bcm/bcm_kona_smc.c
@@ -125,9 +125,7 @@ static int bcm_kona_do_smc(u32 service_id, u32 buffer_phys)
__asmeq("%2", "r4")
__asmeq("%3", "r5")
__asmeq("%4", "r6")
-#ifdef REQUIRES_SEC
".arch_extension sec\n"
-#endif
" smc #0\n"
: "=r" (ip), "=r" (r0)
: "r" (r4), "r" (r5), "r" (r6)
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index cd00c82a1add..44de9f36fd1b 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -14,9 +14,5 @@ obj-$(CONFIG_PM_SLEEP) += suspend.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep.o :=-Wa,-march=armv7-a$(plus_sec)
-
obj-$(CONFIG_EXYNOS5420_MCPM) += mcpm-exynos.o
CFLAGS_mcpm-exynos.o += -march=armv7-a
diff --git a/arch/arm/mach-exynos/exynos-smc.S b/arch/arm/mach-exynos/exynos-smc.S
index d259532ba937..392f8ba351f4 100644
--- a/arch/arm/mach-exynos/exynos-smc.S
+++ b/arch/arm/mach-exynos/exynos-smc.S
@@ -10,7 +10,7 @@
/*
* Function signature: void exynos_smc(u32 cmd, u32 arg1, u32 arg2, u32 arg3)
*/
-
+ .arch_extension sec
ENTRY(exynos_smc)
stmfd sp!, {r4-r11, lr}
dsb
diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S
index 2783c3a0c06a..6e3207d486b4 100644
--- a/arch/arm/mach-exynos/sleep.S
+++ b/arch/arm/mach-exynos/sleep.S
@@ -44,7 +44,7 @@ ENTRY(exynos_cpu_resume)
ENDPROC(exynos_cpu_resume)
.align
-
+ .arch_extension sec
ENTRY(exynos_cpu_resume_ns)
mrc p15, 0, r0, c0, c0, 0
ldr r1, =CPU_MASK
diff --git a/arch/arm/mach-highbank/Makefile b/arch/arm/mach-highbank/Makefile
index 55840f414d3e..e7741b883d13 100644
--- a/arch/arm/mach-highbank/Makefile
+++ b/arch/arm/mach-highbank/Makefile
@@ -1,6 +1,3 @@
obj-y := highbank.o system.o smc.o
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec)
-
obj-$(CONFIG_PM_SLEEP) += pm.o
diff --git a/arch/arm/mach-highbank/smc.S b/arch/arm/mach-highbank/smc.S
index 407d17baaaa9..c53d6e37bb30 100644
--- a/arch/arm/mach-highbank/smc.S
+++ b/arch/arm/mach-highbank/smc.S
@@ -16,7 +16,7 @@
* the monitor API number.
* Function signature : void highbank_smc1(u32 fn, u32 arg)
*/
-
+ .arch_extension sec
ENTRY(highbank_smc1)
stmfd sp!, {r4-r11, lr}
mov r12, r0
diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile
index f8b0dccac8dc..739b38be5696 100644
--- a/arch/arm/mach-keystone/Makefile
+++ b/arch/arm/mach-keystone/Makefile
@@ -1,9 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := keystone.o smc.o
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_smc.o :=-Wa,-march=armv7-a$(plus_sec)
-
obj-$(CONFIG_SMP) += platsmp.o
# PM domain driver for Keystone SOCs
diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S
index d15de8179fab..b105a465bc16 100644
--- a/arch/arm/mach-keystone/smc.S
+++ b/arch/arm/mach-keystone/smc.S
@@ -21,6 +21,7 @@
*
* Return: Non zero value on failure
*/
+ .arch_extension sec
ENTRY(keystone_cpu_smc)
stmfd sp!, {r4-r11, lr}
smc #0
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 85d1b13c9215..f1d283995b31 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -41,11 +41,6 @@ obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o
obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_omap-smc.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep44xx.o :=-Wa,-march=armv7-a$(plus_sec)
-
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
obj-$(CONFIG_SOC_OMAP2430) += sram243x.o
@@ -95,9 +90,6 @@ obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
obj-$(CONFIG_POWER_AVS_OMAP_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
-AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
-AFLAGS_sleep43xx.o :=-Wa,-march=armv7-a$(plus_sec)
endif
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 4c6f14cf92a8..605b9fa9ba9b 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -58,6 +58,7 @@ ENDPROC(omap5_secondary_startup)
* omap5_secondary_startup if the primary CPU was put into HYP mode by
* the boot loader.
*/
+ .arch_extension sec
ENTRY(omap5_secondary_hyp_startup)
wait_2: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0
ldr r0, [r2]
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index 72506e6cf9e7..b71a92eaffc9 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -23,7 +23,7 @@
* link register "lr".
* Function signature : void omap_smc1(u32 fn, u32 arg)
*/
-
+ .arch_extension sec
ENTRY(omap_smc1)
stmfd sp!, {r2-r12, lr}
mov r12, r0
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 22daf4efed68..42a9bff8c53b 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -97,6 +97,7 @@ ENDPROC(enable_omap3630_toggle_l2_on_restore)
*
* r0 = physical address of the parameters
*/
+ .arch_extension sec
ENTRY(save_secure_ram_context)
stmfd sp!, {r4 - r11, lr} @ save registers on stack
mov r3, r0 @ physical address of parameters
diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index 5b9343b58fc7..19d78d8a6bc9 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -56,6 +56,7 @@
#define RTC_PMIC_EXT_WAKEUP_EN BIT(0)
.arm
+ .arch_extension sec
.align 3
ENTRY(am43xx_do_wfi)
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 0cae3b070208..55afed959a9a 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -23,6 +23,7 @@
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
+ .arch_extension sec
.macro DO_SMC
dsb
smc #0
diff --git a/arch/arm/mach-tango/Makefile b/arch/arm/mach-tango/Makefile
index da6c633d3cc0..97cd04508fa1 100644
--- a/arch/arm/mach-tango/Makefile
+++ b/arch/arm/mach-tango/Makefile
@@ -1,7 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-plus_sec := $(call as-instr,.arch_extension sec,+sec)
-AFLAGS_smc.o := -Wa,-march=armv7-a$(plus_sec)
-
obj-y += setup.o smc.o
obj-$(CONFIG_SMP) += platsmp.o
obj-$(CONFIG_SUSPEND) += pm.o
diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
index 361a8dc89804..cf2d21e5226c 100644
--- a/arch/arm/mach-tango/smc.S
+++ b/arch/arm/mach-tango/smc.S
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
#include <linux/linkage.h>
+ .arch_extension sec
ENTRY(tango_smc)
push {lr}
mov ip, r1
--
2.21.0
The label mvebu_boot_wa_start is not necessary and causes a build
issue when building with LLVM's integrated assembler:
AS arch/arm/mach-mvebu/pmsu_ll.o
arch/arm/mach-mvebu/pmsu_ll.S:59:1: error: invalid symbol redefinition
mvebu_boot_wa_start:
^
Drop the label.
Signed-off-by: Stefan Agner <[email protected]>
---
arch/arm/mach-mvebu/pmsu_ll.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
index 88651221dbdd..c1fb713e9306 100644
--- a/arch/arm/mach-mvebu/pmsu_ll.S
+++ b/arch/arm/mach-mvebu/pmsu_ll.S
@@ -56,7 +56,6 @@ ENDPROC(armada_38x_cpu_resume)
/* The following code will be executed from SRAM */
ENTRY(mvebu_boot_wa_start)
-mvebu_boot_wa_start:
ARM_BE8(setend be)
adr r0, 1f
ldr r0, [r0] @ load the address of the
--
2.21.0
In every other instance where mrc is used the coprocessor operand
is prefix with p (e.g. p15). Use the p prefix in this case too.
This fixes a build issue when using LLVM's integrated assembler:
arch/arm/mach-mvebu/coherency_ll.S:69:6: error: invalid operand for instruction
mrc 15, 0, r3, cr0, cr0, 5
^
arch/arm/mach-mvebu/pmsu_ll.S:19:6: error: invalid operand for instruction
mrc 15, 0, r0, cr0, cr0, 5 @ get the CPU ID
^
Signed-off-by: Stefan Agner <[email protected]>
---
arch/arm/mach-mvebu/coherency_ll.S | 2 +-
arch/arm/mach-mvebu/pmsu_ll.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
index 8b2fbc8b6bc6..2d962fe48821 100644
--- a/arch/arm/mach-mvebu/coherency_ll.S
+++ b/arch/arm/mach-mvebu/coherency_ll.S
@@ -66,7 +66,7 @@ ENDPROC(ll_get_coherency_base)
* fabric registers
*/
ENTRY(ll_get_coherency_cpumask)
- mrc 15, 0, r3, cr0, cr0, 5
+ mrc p15, 0, r3, cr0, cr0, 5
and r3, r3, #15
mov r2, #(1 << 24)
lsl r3, r2, r3
diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
index c1fb713e9306..7aae9a25cfeb 100644
--- a/arch/arm/mach-mvebu/pmsu_ll.S
+++ b/arch/arm/mach-mvebu/pmsu_ll.S
@@ -16,7 +16,7 @@
ENTRY(armada_38x_scu_power_up)
mrc p15, 4, r1, c15, c0 @ get SCU base address
orr r1, r1, #0x8 @ SCU CPU Power Status Register
- mrc 15, 0, r0, cr0, cr0, 5 @ get the CPU ID
+ mrc p15, 0, r0, cr0, cr0, 5 @ get the CPU ID
and r0, r0, #15
add r1, r1, r0
mov r0, #0x0
--
2.21.0
Stefan Agner <[email protected]> writes:
> The LLVM Target parser currently does not allow to specify the security
> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
> to use Clang with LLVM's integrated assembler, this leads to a build
> errors such as this:
> clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>
> Use ".arch_extension sec" to enable the security extension in a more
> portable fasion.
>
> Note that this is technically not exactly the same as the old code
> checked for availabilty of the security extension by calling as-instr.
> However, there are already other sites which use ".arch_extension sec"
> unconditionally, hence de-facto we need an assembler capable of
> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
> arch extension "sec" is available since binutils 2.21 according to
> its documentation [1].
>
> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>
> Signed-off-by: Stefan Agner <[email protected]>
> ---
> arch/arm/mach-bcm/Makefile | 3 ---
> arch/arm/mach-bcm/bcm_kona_smc.c | 2 --
> arch/arm/mach-exynos/Makefile | 4 ----
> arch/arm/mach-exynos/exynos-smc.S | 2 +-
> arch/arm/mach-exynos/sleep.S | 2 +-
> arch/arm/mach-highbank/Makefile | 3 ---
> arch/arm/mach-highbank/smc.S | 2 +-
> arch/arm/mach-keystone/Makefile | 3 ---
> arch/arm/mach-keystone/smc.S | 1 +
> arch/arm/mach-omap2/Makefile | 8 --------
> arch/arm/mach-omap2/omap-headsmp.S | 1 +
> arch/arm/mach-omap2/omap-smc.S | 2 +-
> arch/arm/mach-omap2/sleep34xx.S | 1 +
> arch/arm/mach-omap2/sleep43xx.S | 1 +
> arch/arm/mach-omap2/sleep44xx.S | 1 +
> arch/arm/mach-tango/Makefile | 3 ---
> arch/arm/mach-tango/smc.S | 1 +
> 17 files changed, 10 insertions(+), 30 deletions(-)
[...]
> diff --git a/arch/arm/mach-tango/Makefile b/arch/arm/mach-tango/Makefile
> index da6c633d3cc0..97cd04508fa1 100644
> --- a/arch/arm/mach-tango/Makefile
> +++ b/arch/arm/mach-tango/Makefile
> @@ -1,7 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> -plus_sec := $(call as-instr,.arch_extension sec,+sec)
> -AFLAGS_smc.o := -Wa,-march=armv7-a$(plus_sec)
> -
> obj-y += setup.o smc.o
> obj-$(CONFIG_SMP) += platsmp.o
> obj-$(CONFIG_SUSPEND) += pm.o
> diff --git a/arch/arm/mach-tango/smc.S b/arch/arm/mach-tango/smc.S
> index 361a8dc89804..cf2d21e5226c 100644
> --- a/arch/arm/mach-tango/smc.S
> +++ b/arch/arm/mach-tango/smc.S
> @@ -1,6 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #include <linux/linkage.h>
>
> + .arch_extension sec
> ENTRY(tango_smc)
> push {lr}
> mov ip, r1
For Tango:
Acked-by: Mans Rullgard <[email protected]>
--
M?ns Rullg?rd
On Sat, 23 Mar 2019, Stefan Agner wrote:
> The label mvebu_boot_wa_start is not necessary and causes a build
> issue when building with LLVM's integrated assembler:
> AS arch/arm/mach-mvebu/pmsu_ll.o
> arch/arm/mach-mvebu/pmsu_ll.S:59:1: error: invalid symbol redefinition
> mvebu_boot_wa_start:
> ^
>
> Drop the label.
>
> Signed-off-by: Stefan Agner <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
> ---
> arch/arm/mach-mvebu/pmsu_ll.S | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
> index 88651221dbdd..c1fb713e9306 100644
> --- a/arch/arm/mach-mvebu/pmsu_ll.S
> +++ b/arch/arm/mach-mvebu/pmsu_ll.S
> @@ -56,7 +56,6 @@ ENDPROC(armada_38x_cpu_resume)
>
> /* The following code will be executed from SRAM */
> ENTRY(mvebu_boot_wa_start)
> -mvebu_boot_wa_start:
> ARM_BE8(setend be)
> adr r0, 1f
> ldr r0, [r0] @ load the address of the
> --
> 2.21.0
>
>
On Sat, 23 Mar 2019, Stefan Agner wrote:
> In every other instance where mrc is used the coprocessor operand
> is prefix with p (e.g. p15). Use the p prefix in this case too.
> This fixes a build issue when using LLVM's integrated assembler:
> arch/arm/mach-mvebu/coherency_ll.S:69:6: error: invalid operand for instruction
> mrc 15, 0, r3, cr0, cr0, 5
> ^
> arch/arm/mach-mvebu/pmsu_ll.S:19:6: error: invalid operand for instruction
> mrc 15, 0, r0, cr0, cr0, 5 @ get the CPU ID
> ^
>
> Signed-off-by: Stefan Agner <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
> ---
> arch/arm/mach-mvebu/coherency_ll.S | 2 +-
> arch/arm/mach-mvebu/pmsu_ll.S | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
> index 8b2fbc8b6bc6..2d962fe48821 100644
> --- a/arch/arm/mach-mvebu/coherency_ll.S
> +++ b/arch/arm/mach-mvebu/coherency_ll.S
> @@ -66,7 +66,7 @@ ENDPROC(ll_get_coherency_base)
> * fabric registers
> */
> ENTRY(ll_get_coherency_cpumask)
> - mrc 15, 0, r3, cr0, cr0, 5
> + mrc p15, 0, r3, cr0, cr0, 5
> and r3, r3, #15
> mov r2, #(1 << 24)
> lsl r3, r2, r3
> diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
> index c1fb713e9306..7aae9a25cfeb 100644
> --- a/arch/arm/mach-mvebu/pmsu_ll.S
> +++ b/arch/arm/mach-mvebu/pmsu_ll.S
> @@ -16,7 +16,7 @@
> ENTRY(armada_38x_scu_power_up)
> mrc p15, 4, r1, c15, c0 @ get SCU base address
> orr r1, r1, #0x8 @ SCU CPU Power Status Register
> - mrc 15, 0, r0, cr0, cr0, 5 @ get the CPU ID
> + mrc p15, 0, r0, cr0, cr0, 5 @ get the CPU ID
> and r0, r0, #15
> add r1, r1, r0
> mov r0, #0x0
> --
> 2.21.0
>
>
On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <[email protected]> wrote:
>
> The LLVM Target parser currently does not allow to specify the security
> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
> to use Clang with LLVM's integrated assembler, this leads to a build
> errors such as this:
> clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>
> Use ".arch_extension sec" to enable the security extension in a more
> portable fasion.
>
> Note that this is technically not exactly the same as the old code
> checked for availabilty of the security extension by calling as-instr.
> However, there are already other sites which use ".arch_extension sec"
> unconditionally, hence de-facto we need an assembler capable of
> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
> arch extension "sec" is available since binutils 2.21 according to
> its documentation [1].
>
> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>
> Signed-off-by: Stefan Agner <[email protected]>
This sounds like a good idea. I think we have platform specific
minimum toolchain versions elsewhere, but I don't see a problem
with raising the minimum version for all the armv7ve platforms.
I've added this patch to my randconfig test queue, but please
send it to [email protected] for inclusion when you have
collected more Acks.
Do you have a git tree with other patches required for the
integrated assembler? I might try that out as well with
my randconfig tree. At the moment I'm building with
clang-8 and a small number of patches on top.
Acked-by: Arnd Bergmann <[email protected]>
On 23.03.2019 21:06, Arnd Bergmann wrote:
> On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <[email protected]> wrote:
>>
>> The LLVM Target parser currently does not allow to specify the security
>> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
>> to use Clang with LLVM's integrated assembler, this leads to a build
>> errors such as this:
>> clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>>
>> Use ".arch_extension sec" to enable the security extension in a more
>> portable fasion.
>>
>> Note that this is technically not exactly the same as the old code
>> checked for availabilty of the security extension by calling as-instr.
>> However, there are already other sites which use ".arch_extension sec"
>> unconditionally, hence de-facto we need an assembler capable of
>> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
>> arch extension "sec" is available since binutils 2.21 according to
>> its documentation [1].
>>
>> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
>> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>>
>> Signed-off-by: Stefan Agner <[email protected]>
>
> This sounds like a good idea. I think we have platform specific
> minimum toolchain versions elsewhere, but I don't see a problem
> with raising the minimum version for all the armv7ve platforms.
>
> I've added this patch to my randconfig test queue, but please
> send it to [email protected] for inclusion when you have
> collected more Acks.
Cool, will do!
>
> Do you have a git tree with other patches required for the
> integrated assembler? I might try that out as well with
> my randconfig tree. At the moment I'm building with
> clang-8 and a small number of patches on top.
I do have some more work in progress patches. I made some rough commits
and pushed the tree here:
https://github.com/ClangBuiltLinux/linux/commits/arm-fixes-hacks-to-make-llvm-integrated-as-work
This tree compiles for me and a test boot with qemu seems to work.
It seems that LLVM's integrated assembler is capable of assembling
almost the whole kernel a lot can be worked around/fixed on kernel side.
There are only about a handful of files where I still use the GNU
assembler. Haven't looked closely at these cases yet.
There is one issue which probably need a change in LLVM:
https://github.com/ClangBuiltLinux/linux/issues/306
I proposed this fix:
https://reviews.llvm.org/D59733
>
> Acked-by: Arnd Bergmann <[email protected]>
Thx.
--
Stefan
On Sat, 23 Mar 2019 at 16:52, Stefan Agner <[email protected]> wrote:
>
> The LLVM Target parser currently does not allow to specify the security
> extension as part of -march (see also LLVM Bug 40186 [0]). When trying
> to use Clang with LLVM's integrated assembler, this leads to a build
> errors such as this:
> clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>
> Use ".arch_extension sec" to enable the security extension in a more
> portable fasion.
>
> Note that this is technically not exactly the same as the old code
> checked for availabilty of the security extension by calling as-instr.
> However, there are already other sites which use ".arch_extension sec"
> unconditionally, hence de-facto we need an assembler capable of
> ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
> arch extension "sec" is available since binutils 2.21 according to
> its documentation [1].
>
> [0] https://bugs.llvm.org/show_bug.cgi?id=40186
> [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>
> Signed-off-by: Stefan Agner <[email protected]>
> ---
> arch/arm/mach-bcm/Makefile | 3 ---
> arch/arm/mach-bcm/bcm_kona_smc.c | 2 --
> arch/arm/mach-exynos/Makefile | 4 ----
> arch/arm/mach-exynos/exynos-smc.S | 2 +-
> arch/arm/mach-exynos/sleep.S | 2 +-
for Exynos:
Acked-by: Krzysztof Kozlowski <[email protected]>
Best regards,
Krzysztof
On Sun, Mar 24, 2019 at 3:06 AM Arnd Bergmann <[email protected]> wrote:
>
> On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <[email protected]> wrote:
> >
> > The LLVM Target parser currently does not allow to specify the security
> > extension as part of -march (see also LLVM Bug 40186 [0]). When trying
> > to use Clang with LLVM's integrated assembler, this leads to a build
> > errors such as this:
> > clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
> >
> > Use ".arch_extension sec" to enable the security extension in a more
> > portable fasion.
> >
> > Note that this is technically not exactly the same as the old code
> > checked for availabilty of the security extension by calling as-instr.
> > However, there are already other sites which use ".arch_extension sec"
> > unconditionally, hence de-facto we need an assembler capable of
> > ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
> > arch extension "sec" is available since binutils 2.21 according to
> > its documentation [1].
> >
> > [0] https://bugs.llvm.org/show_bug.cgi?id=40186
> > [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
> >
> > Signed-off-by: Stefan Agner <[email protected]>
>
> This sounds like a good idea. I think we have platform specific
> minimum toolchain versions elsewhere, but I don't see a problem
> with raising the minimum version for all the armv7ve platforms.
>
> I've added this patch to my randconfig test queue, but please
> send it to [email protected] for inclusion when you have
> collected more Acks.
>
> Do you have a git tree with other patches required for the
> integrated assembler? I might try that out as well with
> my randconfig tree. At the moment I'm building with
> clang-8 and a small number of patches on top.
>
> Acked-by: Arnd Bergmann <[email protected]>
I only now looked at the results and found a problem:
In a mixed v6/v7 configuration, the arch_extension flag
is not sufficient, and for armv6+sec, we get failures like
/git/arm-soc/arch/arm/mach-omap2/sleep44xx.S: Assembler messages:
/git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:343: Error: selected
processor does not support `isb' in ARM mode
/git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:350: Error: selected
processor does not support `dsb' in ARM mode
/git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:351: Error: selected
processor does not support `dmb' in ARM mode
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
/git/arm-soc/scripts/Makefile.build:369: recipe for target
'arch/arm/mach-omap2/sleep44xx.o' failed
make[3]: *** [arch/arm/mach-omap2/sleep44xx.o] Error 1
==> build/arm/0x64728DCE_defconfig/log <==
/git/arm-soc/arch/arm/mach-omap2/omap-smc.S: Assembler messages:
/git/arm-soc/arch/arm/mach-omap2/omap-smc.S:31: Error: selected
processor does not support `dsb' in ARM mode
/git/arm-soc/arch/arm/mach-omap2/omap-smc.S:53: Error: selected
processor does not support `dsb' in ARM mode
/git/arm-soc/arch/arm/mach-omap2/omap-smc.S:54: Error: selected
processor does not support `dmb' in ARM mode
Arnd
On 31.03.2019 19:34, Arnd Bergmann wrote:
> On Sun, Mar 24, 2019 at 3:06 AM Arnd Bergmann <[email protected]> wrote:
>>
>> On Sat, Mar 23, 2019 at 4:52 PM Stefan Agner <[email protected]> wrote:
>> >
>> > The LLVM Target parser currently does not allow to specify the security
>> > extension as part of -march (see also LLVM Bug 40186 [0]). When trying
>> > to use Clang with LLVM's integrated assembler, this leads to a build
>> > errors such as this:
>> > clang-8: error: the clang compiler does not support '-Wa,-march=armv7-a+sec'
>> >
>> > Use ".arch_extension sec" to enable the security extension in a more
>> > portable fasion.
>> >
>> > Note that this is technically not exactly the same as the old code
>> > checked for availabilty of the security extension by calling as-instr.
>> > However, there are already other sites which use ".arch_extension sec"
>> > unconditionally, hence de-facto we need an assembler capable of
>> > ".arch_extension sec" already today (arch/arm/mm/proc-v7.S). The
>> > arch extension "sec" is available since binutils 2.21 according to
>> > its documentation [1].
>> >
>> > [0] https://bugs.llvm.org/show_bug.cgi?id=40186
>> > [1] https://sourceware.org/binutils/docs-2.21/as/ARM-Options.html
>> >
>> > Signed-off-by: Stefan Agner <[email protected]>
>>
>> This sounds like a good idea. I think we have platform specific
>> minimum toolchain versions elsewhere, but I don't see a problem
>> with raising the minimum version for all the armv7ve platforms.
>>
>> I've added this patch to my randconfig test queue, but please
>> send it to [email protected] for inclusion when you have
>> collected more Acks.
>>
>> Do you have a git tree with other patches required for the
>> integrated assembler? I might try that out as well with
>> my randconfig tree. At the moment I'm building with
>> clang-8 and a small number of patches on top.
>>
>> Acked-by: Arnd Bergmann <[email protected]>
>
> I only now looked at the results and found a problem:
> In a mixed v6/v7 configuration, the arch_extension flag
> is not sufficient, and for armv6+sec, we get failures like
>
> /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S: Assembler messages:
> /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:343: Error: selected
> processor does not support `isb' in ARM mode
> /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:350: Error: selected
> processor does not support `dsb' in ARM mode
> /git/arm-soc/arch/arm/mach-omap2/sleep44xx.S:351: Error: selected
> processor does not support `dmb' in ARM mode
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> /git/arm-soc/scripts/Makefile.build:369: recipe for target
> 'arch/arm/mach-omap2/sleep44xx.o' failed
> make[3]: *** [arch/arm/mach-omap2/sleep44xx.o] Error 1
>
> ==> build/arm/0x64728DCE_defconfig/log <==
> /git/arm-soc/arch/arm/mach-omap2/omap-smc.S: Assembler messages:
> /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:31: Error: selected
> processor does not support `dsb' in ARM mode
> /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:53: Error: selected
> processor does not support `dsb' in ARM mode
> /git/arm-soc/arch/arm/mach-omap2/omap-smc.S:54: Error: selected
> processor does not support `dmb' in ARM mode
Hm, I guess I can just use .arch armv7-a in those cases, as we use in
other places.
Thanks for testing! Will send a v2.
--
Stefan