* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-21 17:27 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-21 17:27 UTC (permalink / raw)
To: linux, linux-arm-kernel, lkml; +Cc: Jason A. Donenfeld, stable
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in mysterious and buggy circumstances. In order to homogenize
this behavior, rather than adding 1, we simply OR in 1, so that already
unaligned instructions don't change. This fix is required for a
pedestrian THUMB2_KERNEL to boot without crashing when built with
non-old binutils.
While it works, the downside is that we have to add an `orr` instruction
to a fast path. The assembler can't do this at assemble time via "|1"
because "invalid operands (.text and *ABS* sections) for `|'", so we're
forced to do this. A better solution would be to have consistent
binutils behavior, or to have some kind of \sym feature detection that
won't turn into a maze of version comparisons. However, it's at the
moment unclear how to achieve this.
The rest of this commit message contains all of the relevant
information.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C↓j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA↓o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable@vger.kernel.org
---
arch/arm/include/asm/assembler.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index ad301f107dd2..c62a3b6b0a3e 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -194,10 +194,9 @@
*/
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
-#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
-#else
adr\c \rd, \sym
+#ifdef CONFIG_THUMB2_KERNEL
+ orr\c \rd, \rd, 1
#endif
.endm
.endr
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-21 17:27 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-21 17:27 UTC (permalink / raw)
To: linux-arm-kernel
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in mysterious and buggy circumstances. In order to homogenize
this behavior, rather than adding 1, we simply OR in 1, so that already
unaligned instructions don't change. This fix is required for a
pedestrian THUMB2_KERNEL to boot without crashing when built with
non-old binutils.
While it works, the downside is that we have to add an `orr` instruction
to a fast path. The assembler can't do this at assemble time via "|1"
because "invalid operands (.text and *ABS* sections) for `|'", so we're
forced to do this. A better solution would be to have consistent
binutils behavior, or to have some kind of \sym feature detection that
won't turn into a maze of version comparisons. However, it's at the
moment unclear how to achieve this.
The rest of this commit message contains all of the relevant
information.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C?j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA?o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable at vger.kernel.org
---
arch/arm/include/asm/assembler.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index ad301f107dd2..c62a3b6b0a3e 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -194,10 +194,9 @@
*/
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
-#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
-#else
adr\c \rd, \sym
+#ifdef CONFIG_THUMB2_KERNEL
+ orr\c \rd, \rd, 1
#endif
.endm
.endr
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-21 17:27 ` Jason A. Donenfeld
@ 2017-11-21 17:38 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-21 17:38 UTC (permalink / raw)
To: Jason A. Donenfeld, Will Deacon; +Cc: linux-arm-kernel, lkml, stable
On Tue, Nov 21, 2017 at 06:27:51PM +0100, Jason A. Donenfeld wrote:
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in mysterious and buggy circumstances. In order to homogenize
> this behavior, rather than adding 1, we simply OR in 1, so that already
> unaligned instructions don't change. This fix is required for a
> pedestrian THUMB2_KERNEL to boot without crashing when built with
> non-old binutils.
>
> While it works, the downside is that we have to add an `orr` instruction
> to a fast path. The assembler can't do this at assemble time via "|1"
> because "invalid operands (.text and *ABS* sections) for `|'", so we're
> forced to do this. A better solution would be to have consistent
> binutils behavior, or to have some kind of \sym feature detection that
> won't turn into a maze of version comparisons. However, it's at the
> moment unclear how to achieve this.
>
> The rest of this commit message contains all of the relevant
> information.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> These produced the following code:
> --- broken 2017-11-21 17:44:14.523416082 +0100
> +++ working 2017-11-21 17:44:44.548461234 +0100
> @@ -133,7 +133,7 @@
> 160: f01a 0ff0 tst.w sl, #240 ; 0xf0
> 164: d111 bne.n 18a <__sys_trace>
> 166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
> - 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
> + 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
> 16e: bf38 it cc
> 170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
> 174: a902 add r1, sp, #8
>
> The differing instruction corresponds with this actual line in
> arch/arm/kernel/entry-common.S:
> badr lr, ret_fast_syscall @ return address
>
> Running the broken kernel results in a runtime OOPS with:
> PC is at ret_fast_syscall+0x4/0x52
> LR is at ret_fast_syscall+0x2/0x52
>
> The disassembly of that function for the crashing kernel is:
> .text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C↓j
> .text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
> .text:00000002
> .text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA↓o
> .text:00000002 LDR.W R2, [R9,#8]
> .text:00000006 CMP.W R2, #0xBF000000
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
As it just seems to be a limited range of binutils versions that are
affected, I'd rather not impact the kernel fast-paths with extra
cycles just because binutils decided to change behaviour. I'd prefer
to inform people about the problem and get them to change to a non-
buggy binutils.
This seems to be the second binutils bug that's biting us within the
last month... what's going on with binutils QA?
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 1cfac5119545..9e70d0435121 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..fa77351ccefd 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
index e69de29bb2d1..97bbeeb691da 100644
--- a/arch/arm/tools/toolcheck
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,24 @@
+#!/bin/sh -ex
+if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
+ tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
+ cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+test:
+ mov r0, #0
+ badr lr, test
+EOF
+ if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
+ echo "Error: your assembler version produces buggy kernels" >&2
+ $AS --version | head -n1 >&2
+ rm $tmp/*.o
+ rmdir $tmp
+ exit 1
+ fi
+ rm $tmp/*.o
+ rmdir $tmp
+fi
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-21 17:38 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-21 17:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 21, 2017 at 06:27:51PM +0100, Jason A. Donenfeld wrote:
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in mysterious and buggy circumstances. In order to homogenize
> this behavior, rather than adding 1, we simply OR in 1, so that already
> unaligned instructions don't change. This fix is required for a
> pedestrian THUMB2_KERNEL to boot without crashing when built with
> non-old binutils.
>
> While it works, the downside is that we have to add an `orr` instruction
> to a fast path. The assembler can't do this at assemble time via "|1"
> because "invalid operands (.text and *ABS* sections) for `|'", so we're
> forced to do this. A better solution would be to have consistent
> binutils behavior, or to have some kind of \sym feature detection that
> won't turn into a maze of version comparisons. However, it's at the
> moment unclear how to achieve this.
>
> The rest of this commit message contains all of the relevant
> information.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> These produced the following code:
> --- broken 2017-11-21 17:44:14.523416082 +0100
> +++ working 2017-11-21 17:44:44.548461234 +0100
> @@ -133,7 +133,7 @@
> 160: f01a 0ff0 tst.w sl, #240 ; 0xf0
> 164: d111 bne.n 18a <__sys_trace>
> 166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
> - 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
> + 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
> 16e: bf38 it cc
> 170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
> 174: a902 add r1, sp, #8
>
> The differing instruction corresponds with this actual line in
> arch/arm/kernel/entry-common.S:
> badr lr, ret_fast_syscall @ return address
>
> Running the broken kernel results in a runtime OOPS with:
> PC is at ret_fast_syscall+0x4/0x52
> LR is at ret_fast_syscall+0x2/0x52
>
> The disassembly of that function for the crashing kernel is:
> .text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C?j
> .text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
> .text:00000002
> .text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA?o
> .text:00000002 LDR.W R2, [R9,#8]
> .text:00000006 CMP.W R2, #0xBF000000
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
As it just seems to be a limited range of binutils versions that are
affected, I'd rather not impact the kernel fast-paths with extra
cycles just because binutils decided to change behaviour. I'd prefer
to inform people about the problem and get them to change to a non-
buggy binutils.
This seems to be the second binutils bug that's biting us within the
last month... what's going on with binutils QA?
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 1cfac5119545..9e70d0435121 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..fa77351ccefd 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
index e69de29bb2d1..97bbeeb691da 100644
--- a/arch/arm/tools/toolcheck
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,24 @@
+#!/bin/sh -ex
+if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
+ tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
+ cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+test:
+ mov r0, #0
+ badr lr, test
+EOF
+ if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
+ echo "Error: your assembler version produces buggy kernels" >&2
+ $AS --version | head -n1 >&2
+ rm $tmp/*.o
+ rmdir $tmp
+ exit 1
+ fi
+ rm $tmp/*.o
+ rmdir $tmp
+fi
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-21 17:38 ` Russell King - ARM Linux
@ 2017-11-21 17:46 ` Jason A. Donenfeld
-1 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-21 17:46 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Will Deacon, linux-arm-kernel, lkml, stable
Hi Russell,
On Tue, Nov 21, 2017 at 6:38 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> +toolcheck:
> + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
Perhaps faster to put the check for THUMB2_KERNEL around the make
target, instead of doing it in the code?
> +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
See above.
> + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> + .syntax unified
> + .thumb
> + .macro badr, reg, sym
> + adr \reg, \sym + 1
> + .endm
> +
> +test:
> + mov r0, #0
> + badr lr, test
> +EOF
> + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> + echo "Error: your assembler version produces buggy kernels" >&2
> + $AS --version | head -n1 >&2
> + rm $tmp/*.o
> + rmdir $tmp
> + exit 1
> + fi
> + rm $tmp/*.o
> + rmdir $tmp
> +fi
This doesn't actually catch the issues. In the buggy binutils, it
appears that sometimes adr grabs the right symbol and sometimes it
doesn't. I'm not yet able to figure out a minimal condition for it
going one way or the other.
Jason
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-21 17:46 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-21 17:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
On Tue, Nov 21, 2017 at 6:38 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> +toolcheck:
> + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
Perhaps faster to put the check for THUMB2_KERNEL around the make
target, instead of doing it in the code?
> +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
See above.
> + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> + .syntax unified
> + .thumb
> + .macro badr, reg, sym
> + adr \reg, \sym + 1
> + .endm
> +
> +test:
> + mov r0, #0
> + badr lr, test
> +EOF
> + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> + echo "Error: your assembler version produces buggy kernels" >&2
> + $AS --version | head -n1 >&2
> + rm $tmp/*.o
> + rmdir $tmp
> + exit 1
> + fi
> + rm $tmp/*.o
> + rmdir $tmp
> +fi
This doesn't actually catch the issues. In the buggy binutils, it
appears that sometimes adr grabs the right symbol and sometimes it
doesn't. I'm not yet able to figure out a minimal condition for it
going one way or the other.
Jason
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-21 17:46 ` Jason A. Donenfeld
@ 2017-11-21 17:49 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-21 17:49 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Will Deacon, linux-arm-kernel, lkml, stable
On Tue, Nov 21, 2017 at 06:46:25PM +0100, Jason A. Donenfeld wrote:
> Hi Russell,
>
> On Tue, Nov 21, 2017 at 6:38 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > +toolcheck:
> > + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
>
> Perhaps faster to put the check for THUMB2_KERNEL around the make
> target, instead of doing it in the code?
Could do, I was debating about extending this for the buggy linker
problem too from a few weeks ago.
> > +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
>
> See above.
>
> > + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> > + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> > + .syntax unified
> > + .thumb
> > + .macro badr, reg, sym
> > + adr \reg, \sym + 1
> > + .endm
> > +
> > +test:
> > + mov r0, #0
> > + badr lr, test
> > +EOF
> > + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> > + echo "Error: your assembler version produces buggy kernels" >&2
> > + $AS --version | head -n1 >&2
> > + rm $tmp/*.o
> > + rmdir $tmp
> > + exit 1
> > + fi
> > + rm $tmp/*.o
> > + rmdir $tmp
> > +fi
>
> This doesn't actually catch the issues. In the buggy binutils, it
> appears that sometimes adr grabs the right symbol and sometimes it
> doesn't. I'm not yet able to figure out a minimal condition for it
> going one way or the other.
What if we locate the "badr" instruction to the same offset - does
that trigger the binutils bug? Note that the grep expression will
need updating...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-21 17:49 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-21 17:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 21, 2017 at 06:46:25PM +0100, Jason A. Donenfeld wrote:
> Hi Russell,
>
> On Tue, Nov 21, 2017 at 6:38 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > +toolcheck:
> > + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
>
> Perhaps faster to put the check for THUMB2_KERNEL around the make
> target, instead of doing it in the code?
Could do, I was debating about extending this for the buggy linker
problem too from a few weeks ago.
> > +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
>
> See above.
>
> > + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> > + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> > + .syntax unified
> > + .thumb
> > + .macro badr, reg, sym
> > + adr \reg, \sym + 1
> > + .endm
> > +
> > +test:
> > + mov r0, #0
> > + badr lr, test
> > +EOF
> > + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> > + echo "Error: your assembler version produces buggy kernels" >&2
> > + $AS --version | head -n1 >&2
> > + rm $tmp/*.o
> > + rmdir $tmp
> > + exit 1
> > + fi
> > + rm $tmp/*.o
> > + rmdir $tmp
> > +fi
>
> This doesn't actually catch the issues. In the buggy binutils, it
> appears that sometimes adr grabs the right symbol and sometimes it
> doesn't. I'm not yet able to figure out a minimal condition for it
> going one way or the other.
What if we locate the "badr" instruction to the same offset - does
that trigger the binutils bug? Note that the grep expression will
need updating...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-21 17:49 ` Russell King - ARM Linux
@ 2017-11-22 23:34 ` Jason A. Donenfeld
-1 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-22 23:34 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: Will Deacon, linux-arm-kernel, lkml, stable
On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> What if we locate the "badr" instruction to the same offset - does
> that trigger the binutils bug? Note that the grep expression will
> need updating...
Nope, this too does not reproduce it. I'm having a bit of trouble
making a minimal test case to reproduce it. But I can reproduce it
everytime by simply assembling the file in question using that
binutils.
Jason
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-22 23:34 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-22 23:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> What if we locate the "badr" instruction to the same offset - does
> that trigger the binutils bug? Note that the grep expression will
> need updating...
Nope, this too does not reproduce it. I'm having a bit of trouble
making a minimal test case to reproduce it. But I can reproduce it
everytime by simply assembling the file in question using that
binutils.
Jason
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-22 23:34 ` Jason A. Donenfeld
@ 2017-11-23 10:35 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-23 10:35 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Will Deacon, linux-arm-kernel, lkml, stable
On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > What if we locate the "badr" instruction to the same offset - does
> > that trigger the binutils bug? Note that the grep expression will
> > need updating...
>
> Nope, this too does not reproduce it. I'm having a bit of trouble
> making a minimal test case to reproduce it. But I can reproduce it
> everytime by simply assembling the file in question using that
> binutils.
If it's that hard to reproduce it, it makes me wonder if it's being
caused by some memory allocation being re-used without full
initialisation, and it's reading stale data.
We can't easily build entry-common.o and check it for the problem as the
position of the "local_restart" code depends on various configuration
options.
I found this URL:
https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
and if you search down to around "line 8358", which is in do_adr(),
there is this new code added:
if (inst.reloc.exp.X_op == O_symbol
&& inst.reloc.exp.X_add_symbol != NULL
&& S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
&& THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
inst.reloc.exp.X_add_number += 1;
which would account for the issue you're seeing.
Given that this change breaks openssl, and breaks the kernel, and
this behaviour is something that we've come to rely upon in the
kernel since T2 was introduced, and there's no way around it without
adding additional instructions, I have to ask what the hell binutils
people think they are doing changing the behaviour of the assembler
in such a gratuitous way, and how they think that users of their
crapware are going to be able to write code that assembles correctly
on both pre-2.29 assemblers and post-2.29 assemblers.
Sorry, but gratuitous changes like this in the toolchain really
annoy me, and just give me more reason to stick with my old known
working versions (binutils 2.25, gcc 4.7.4!) rather than move
forward and then not know whether bugs are due to crappy toolchains
or really something wrong in the program.
binutils people need to realise that what they offer is an interface
for converting assembly code into opcodes and if they change the
translation of that in a visible way, people are going to get
annoyed - just like if we in the kernel change the kernel's user
visible API.
IMHO, binutils should have exactly the same rules - if a change causes
a regression for a user, the change is wrong and should be reverted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-23 10:35 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-23 10:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > What if we locate the "badr" instruction to the same offset - does
> > that trigger the binutils bug? Note that the grep expression will
> > need updating...
>
> Nope, this too does not reproduce it. I'm having a bit of trouble
> making a minimal test case to reproduce it. But I can reproduce it
> everytime by simply assembling the file in question using that
> binutils.
If it's that hard to reproduce it, it makes me wonder if it's being
caused by some memory allocation being re-used without full
initialisation, and it's reading stale data.
We can't easily build entry-common.o and check it for the problem as the
position of the "local_restart" code depends on various configuration
options.
I found this URL:
https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
and if you search down to around "line 8358", which is in do_adr(),
there is this new code added:
if (inst.reloc.exp.X_op == O_symbol
&& inst.reloc.exp.X_add_symbol != NULL
&& S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
&& THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
inst.reloc.exp.X_add_number += 1;
which would account for the issue you're seeing.
Given that this change breaks openssl, and breaks the kernel, and
this behaviour is something that we've come to rely upon in the
kernel since T2 was introduced, and there's no way around it without
adding additional instructions, I have to ask what the hell binutils
people think they are doing changing the behaviour of the assembler
in such a gratuitous way, and how they think that users of their
crapware are going to be able to write code that assembles correctly
on both pre-2.29 assemblers and post-2.29 assemblers.
Sorry, but gratuitous changes like this in the toolchain really
annoy me, and just give me more reason to stick with my old known
working versions (binutils 2.25, gcc 4.7.4!) rather than move
forward and then not know whether bugs are due to crappy toolchains
or really something wrong in the program.
binutils people need to realise that what they offer is an interface
for converting assembly code into opcodes and if they change the
translation of that in a visible way, people are going to get
annoyed - just like if we in the kernel change the kernel's user
visible API.
IMHO, binutils should have exactly the same rules - if a change causes
a regression for a user, the change is wrong and should be reverted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-23 10:35 ` Russell King - ARM Linux
@ 2017-11-23 10:47 ` Jason A. Donenfeld
-1 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 10:47 UTC (permalink / raw)
To: nickc, binutils; +Cc: stable, linux-arm-kernel, Russell King - ARM Linux, LKML
Hello Nick & Binutils developers,
It would appear that recent changes in the binutils assembler (perhaps
52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
the kernel when compiled in thumb2 mode. We currently do not have a
way of working around your breaking changes without adding additional
runtime instructions, which isn't acceptable for us. Details are
included in the thread below.
Thanks,
Jason
Forwarded conversation
Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
------------------------
From: Jason A. Donenfeld <Jason@zx2c4.com>
Date: Tue, Nov 21, 2017 at 6:27 PM
To: linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, stable@vger.kernel.org
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in mysterious and buggy circumstances. In order to homogenize
this behavior, rather than adding 1, we simply OR in 1, so that already
unaligned instructions don't change. This fix is required for a
pedestrian THUMB2_KERNEL to boot without crashing when built with
non-old binutils.
While it works, the downside is that we have to add an `orr` instruction
to a fast path. The assembler can't do this at assemble time via "|1"
because "invalid operands (.text and *ABS* sections) for `|'", so we're
forced to do this. A better solution would be to have consistent
binutils behavior, or to have some kind of \sym feature detection that
won't turn into a maze of version comparisons. However, it's at the
moment unclear how to achieve this.
The rest of this commit message contains all of the relevant
information.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF:
sys_syscall+1C↓j
.text:00000000 CPSID I ; jumptable
00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF:
sys_syscall-6BA↓o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable@vger.kernel.org
---
arch/arm/include/asm/assembler.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index ad301f107dd2..c62a3b6b0a3e 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -194,10 +194,9 @@
*/
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
-#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
-#else
adr\c \rd, \sym
+#ifdef CONFIG_THUMB2_KERNEL
+ orr\c \rd, \rd, 1
#endif
.endm
.endr
--
2.15.0
----------
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Tue, Nov 21, 2017 at 6:38 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>, Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
stable@vger.kernel.org
As it just seems to be a limited range of binutils versions that are
affected, I'd rather not impact the kernel fast-paths with extra
cycles just because binutils decided to change behaviour. I'd prefer
to inform people about the problem and get them to change to a non-
buggy binutils.
This seems to be the second binutils bug that's biting us within the
last month... what's going on with binutils QA?
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 1cfac5119545..9e70d0435121 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..fa77351ccefd 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
index e69de29bb2d1..97bbeeb691da 100644
--- a/arch/arm/tools/toolcheck
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,24 @@
+#!/bin/sh -ex
+if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
+ tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
+ cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+test:
+ mov r0, #0
+ badr lr, test
+EOF
+ if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
+ echo "Error: your assembler version produces buggy kernels" >&2
+ $AS --version | head -n1 >&2
+ rm $tmp/*.o
+ rmdir $tmp
+ exit 1
+ fi
+ rm $tmp/*.o
+ rmdir $tmp
+fi
----------
From: Jason A. Donenfeld <Jason@zx2c4.com>
Date: Tue, Nov 21, 2017 at 6:46 PM
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
stable@vger.kernel.org
Hi Russell,
This doesn't actually catch the issues. In the buggy binutils, it
appears that sometimes adr grabs the right symbol and sometimes it
doesn't. I'm not yet able to figure out a minimal condition for it
going one way or the other.
Jason
----------
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Thu, Nov 23, 2017 at 11:35 AM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
stable@vger.kernel.org
On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > What if we locate the "badr" instruction to the same offset - does
> > that trigger the binutils bug? Note that the grep expression will
> > need updating...
>
> Nope, this too does not reproduce it. I'm having a bit of trouble
> making a minimal test case to reproduce it. But I can reproduce it
> everytime by simply assembling the file in question using that
> binutils.
If it's that hard to reproduce it, it makes me wonder if it's being
caused by some memory allocation being re-used without full
initialisation, and it's reading stale data.
We can't easily build entry-common.o and check it for the problem as the
position of the "local_restart" code depends on various configuration
options.
I found this URL:
https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
and if you search down to around "line 8358", which is in do_adr(),
there is this new code added:
if (inst.reloc.exp.X_op == O_symbol
&& inst.reloc.exp.X_add_symbol != NULL
&& S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
&& THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
inst.reloc.exp.X_add_number += 1;
which would account for the issue you're seeing.
Given that this change breaks openssl, and breaks the kernel, and
this behaviour is something that we've come to rely upon in the
kernel since T2 was introduced, and there's no way around it without
adding additional instructions, I have to ask what the hell binutils
people think they are doing changing the behaviour of the assembler
in such a gratuitous way, and how they think that users of their
crapware are going to be able to write code that assembles correctly
on both pre-2.29 assemblers and post-2.29 assemblers.
Sorry, but gratuitous changes like this in the toolchain really
annoy me, and just give me more reason to stick with my old known
working versions (binutils 2.25, gcc 4.7.4!) rather than move
forward and then not know whether bugs are due to crappy toolchains
or really something wrong in the program.
binutils people need to realise that what they offer is an interface
for converting assembly code into opcodes and if they change the
translation of that in a visible way, people are going to get
annoyed - just like if we in the kernel change the kernel's user
visible API.
IMHO, binutils should have exactly the same rules - if a change causes
a regression for a user, the change is wrong and should be reverted.
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-23 10:47 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 10:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello Nick & Binutils developers,
It would appear that recent changes in the binutils assembler (perhaps
52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
the kernel when compiled in thumb2 mode. We currently do not have a
way of working around your breaking changes without adding additional
runtime instructions, which isn't acceptable for us. Details are
included in the thread below.
Thanks,
Jason
Forwarded conversation
Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
------------------------
From: Jason A. Donenfeld <Jason@zx2c4.com>
Date: Tue, Nov 21, 2017 at 6:27 PM
To: linux at armlinux.org.uk, linux-arm-kernel at lists.infradead.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, stable at vger.kernel.org
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in mysterious and buggy circumstances. In order to homogenize
this behavior, rather than adding 1, we simply OR in 1, so that already
unaligned instructions don't change. This fix is required for a
pedestrian THUMB2_KERNEL to boot without crashing when built with
non-old binutils.
While it works, the downside is that we have to add an `orr` instruction
to a fast path. The assembler can't do this at assemble time via "|1"
because "invalid operands (.text and *ABS* sections) for `|'", so we're
forced to do this. A better solution would be to have consistent
binutils behavior, or to have some kind of \sym feature detection that
won't turn into a maze of version comparisons. However, it's at the
moment unclear how to achieve this.
The rest of this commit message contains all of the relevant
information.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF:
sys_syscall+1C?j
.text:00000000 CPSID I ; jumptable
00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF:
sys_syscall-6BA?o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable at vger.kernel.org
---
arch/arm/include/asm/assembler.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index ad301f107dd2..c62a3b6b0a3e 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -194,10 +194,9 @@
*/
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
-#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
-#else
adr\c \rd, \sym
+#ifdef CONFIG_THUMB2_KERNEL
+ orr\c \rd, \rd, 1
#endif
.endm
.endr
--
2.15.0
----------
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Tue, Nov 21, 2017 at 6:38 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>, Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
stable at vger.kernel.org
As it just seems to be a limited range of binutils versions that are
affected, I'd rather not impact the kernel fast-paths with extra
cycles just because binutils decided to change behaviour. I'd prefer
to inform people about the problem and get them to change to a non-
buggy binutils.
This seems to be the second binutils bug that's biting us within the
last month... what's going on with binutils QA?
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 1cfac5119545..9e70d0435121 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..fa77351ccefd 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
index e69de29bb2d1..97bbeeb691da 100644
--- a/arch/arm/tools/toolcheck
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,24 @@
+#!/bin/sh -ex
+if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
+ tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
+ cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+test:
+ mov r0, #0
+ badr lr, test
+EOF
+ if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
+ echo "Error: your assembler version produces buggy kernels" >&2
+ $AS --version | head -n1 >&2
+ rm $tmp/*.o
+ rmdir $tmp
+ exit 1
+ fi
+ rm $tmp/*.o
+ rmdir $tmp
+fi
----------
From: Jason A. Donenfeld <Jason@zx2c4.com>
Date: Tue, Nov 21, 2017 at 6:46 PM
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>,
linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
stable at vger.kernel.org
Hi Russell,
This doesn't actually catch the issues. In the buggy binutils, it
appears that sometimes adr grabs the right symbol and sometimes it
doesn't. I'm not yet able to figure out a minimal condition for it
going one way or the other.
Jason
----------
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Thu, Nov 23, 2017 at 11:35 AM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Will Deacon <will.deacon@arm.com>,
linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
stable at vger.kernel.org
On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > What if we locate the "badr" instruction to the same offset - does
> > that trigger the binutils bug? Note that the grep expression will
> > need updating...
>
> Nope, this too does not reproduce it. I'm having a bit of trouble
> making a minimal test case to reproduce it. But I can reproduce it
> everytime by simply assembling the file in question using that
> binutils.
If it's that hard to reproduce it, it makes me wonder if it's being
caused by some memory allocation being re-used without full
initialisation, and it's reading stale data.
We can't easily build entry-common.o and check it for the problem as the
position of the "local_restart" code depends on various configuration
options.
I found this URL:
https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
and if you search down to around "line 8358", which is in do_adr(),
there is this new code added:
if (inst.reloc.exp.X_op == O_symbol
&& inst.reloc.exp.X_add_symbol != NULL
&& S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
&& THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
inst.reloc.exp.X_add_number += 1;
which would account for the issue you're seeing.
Given that this change breaks openssl, and breaks the kernel, and
this behaviour is something that we've come to rely upon in the
kernel since T2 was introduced, and there's no way around it without
adding additional instructions, I have to ask what the hell binutils
people think they are doing changing the behaviour of the assembler
in such a gratuitous way, and how they think that users of their
crapware are going to be able to write code that assembles correctly
on both pre-2.29 assemblers and post-2.29 assemblers.
Sorry, but gratuitous changes like this in the toolchain really
annoy me, and just give me more reason to stick with my old known
working versions (binutils 2.25, gcc 4.7.4!) rather than move
forward and then not know whether bugs are due to crappy toolchains
or really something wrong in the program.
binutils people need to realise that what they offer is an interface
for converting assembly code into opcodes and if they change the
translation of that in a visible way, people are going to get
annoyed - just like if we in the kernel change the kernel's user
visible API.
IMHO, binutils should have exactly the same rules - if a change causes
a regression for a user, the change is wrong and should be reverted.
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH] arm: detect buggy binutils when in thumb2 mode
2017-11-23 10:47 ` Jason A. Donenfeld
@ 2017-11-23 11:48 ` Jason A. Donenfeld
-1 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 11:48 UTC (permalink / raw)
To: nickc, binutils, linux-arm-kernel, linux, linux-kernel
Cc: Jason A. Donenfeld, stable
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in certain circumstances. In order to homogenize this behavior,
rather than adding 1, we could simply OR in 1, so that already unaligned
instructions don't change. While that works, the downside is that we have
to add an `orr` instruction to a fast path. The assembler can't do this at
assemble time via "|1" because "invalid operands (.text and *ABS* sections)
for `|'". A better solution would be to have consistent binutils behavior,
but that ship has sailed.
So, this commit adds a detection mechanism, which began as a small thing
from Russell King that I then rewrote to use pure bash instead of
shelling out, so that it doesn't slow down the build process. The detection
mechanism _could_ be used to modify the assembly we generate, but for now
it's just being used to catch buggy binutils and abort the build process in
that case.
The rest of this commit message contains all of the relevant information
about the boot bug when compiled in thumb2 mode.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C↓j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA↓o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: nickc@redhat.com
Cc: stable@vger.kernel.org
---
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/tools/toolcheck
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 80351e505fd5..bd4e248a7f8f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..0a283756f1c5 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @'$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
new file mode 100644
index 000000000000..04fc44b750d2
--- /dev/null
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,44 @@
+#!/bin/bash
+#
+# Copyright 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
+#
+
+set -e
+
+cleanup() {
+ [[ ! -d $temp ]] || rm -rf "$temp"
+ exit
+}
+trap cleanup INT TERM EXIT
+temp="$(mktemp -d)"
+
+check_thumb2_address() {
+ local disassembly
+
+ $CC $KBUILD_AFLAGS -o "$temp/a.out" -c -xassembler - <<-_EOF
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+ .type test, %function
+ .thumb_func
+ test:
+ mov r0, #0
+ badr lr, test
+ _EOF
+ disassembly="$($OBJDUMP -d "$temp/a.out")"
+
+ [[ $disassembly =~ 4:[[:space:]]*f2af\ 0e07 ]] && return 0
+
+ echo "Error: your assembler version produces buggy kernels:" >&2
+ read < <($AS --version) && echo "$REPLY" >&2
+ [[ $disassembly =~ 4:[[:space:]].*$ ]] && echo "${BASH_REMATCH[0]}" >&2 || echo "$disassembly" >&2
+ return 1
+}
+
+config="$(< .config)"
+[[ $config == *CONFIG_THUMB2_KERNEL=y* ]] && check_thumb2_address
+
+exit 0
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH] arm: detect buggy binutils when in thumb2 mode
@ 2017-11-23 11:48 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 11:48 UTC (permalink / raw)
To: linux-arm-kernel
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in certain circumstances. In order to homogenize this behavior,
rather than adding 1, we could simply OR in 1, so that already unaligned
instructions don't change. While that works, the downside is that we have
to add an `orr` instruction to a fast path. The assembler can't do this at
assemble time via "|1" because "invalid operands (.text and *ABS* sections)
for `|'". A better solution would be to have consistent binutils behavior,
but that ship has sailed.
So, this commit adds a detection mechanism, which began as a small thing
from Russell King that I then rewrote to use pure bash instead of
shelling out, so that it doesn't slow down the build process. The detection
mechanism _could_ be used to modify the assembly we generate, but for now
it's just being used to catch buggy binutils and abort the build process in
that case.
The rest of this commit message contains all of the relevant information
about the boot bug when compiled in thumb2 mode.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C?j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA?o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: nickc at redhat.com
Cc: stable at vger.kernel.org
---
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/tools/toolcheck
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 80351e505fd5..bd4e248a7f8f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..0a283756f1c5 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @'$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
new file mode 100644
index 000000000000..04fc44b750d2
--- /dev/null
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,44 @@
+#!/bin/bash
+#
+# Copyright 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
+#
+
+set -e
+
+cleanup() {
+ [[ ! -d $temp ]] || rm -rf "$temp"
+ exit
+}
+trap cleanup INT TERM EXIT
+temp="$(mktemp -d)"
+
+check_thumb2_address() {
+ local disassembly
+
+ $CC $KBUILD_AFLAGS -o "$temp/a.out" -c -xassembler - <<-_EOF
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+ .type test, %function
+ .thumb_func
+ test:
+ mov r0, #0
+ badr lr, test
+ _EOF
+ disassembly="$($OBJDUMP -d "$temp/a.out")"
+
+ [[ $disassembly =~ 4:[[:space:]]*f2af\ 0e07 ]] && return 0
+
+ echo "Error: your assembler version produces buggy kernels:" >&2
+ read < <($AS --version) && echo "$REPLY" >&2
+ [[ $disassembly =~ 4:[[:space:]].*$ ]] && echo "${BASH_REMATCH[0]}" >&2 || echo "$disassembly" >&2
+ return 1
+}
+
+config="$(< .config)"
+[[ $config == *CONFIG_THUMB2_KERNEL=y* ]] && check_thumb2_address
+
+exit 0
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2] arm: detect buggy binutils when in thumb2 mode
2017-11-23 11:48 ` Jason A. Donenfeld
@ 2017-11-23 11:50 ` Jason A. Donenfeld
-1 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 11:50 UTC (permalink / raw)
To: nickc, binutils, linux-arm-kernel, linux, linux-kernel
Cc: Jason A. Donenfeld, stable
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in certain circumstances. In order to homogenize this behavior,
rather than adding 1, we could simply OR in 1, so that already unaligned
instructions don't change. While that works, the downside is that we have
to add an `orr` instruction to a fast path. The assembler can't do this at
assemble time via "|1" because "invalid operands (.text and *ABS* sections)
for `|'". A better solution would be to have consistent binutils behavior,
but that ship has sailed.
So, this commit adds a detection mechanism, which began as a small thing
from Russell King that I then rewrote to use pure bash instead of
shelling out, so that it doesn't slow down the build process. The detection
mechanism _could_ be used to modify the assembly we generate, but for now
it's just being used to catch buggy binutils and abort the build process in
that case.
The rest of this commit message contains all of the relevant information
about the boot bug when compiled in thumb2 mode.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C↓j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA↓o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: nickc@redhat.com
Cc: stable@vger.kernel.org
---
Had the file mode wrong on the submission from a second ago, sorry about
that.
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 3 deletions(-)
create mode 100755 arch/arm/tools/toolcheck
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 80351e505fd5..bd4e248a7f8f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..0a283756f1c5 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @'$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
new file mode 100755
index 000000000000..04fc44b750d2
--- /dev/null
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,44 @@
+#!/bin/bash
+#
+# Copyright 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
+#
+
+set -e
+
+cleanup() {
+ [[ ! -d $temp ]] || rm -rf "$temp"
+ exit
+}
+trap cleanup INT TERM EXIT
+temp="$(mktemp -d)"
+
+check_thumb2_address() {
+ local disassembly
+
+ $CC $KBUILD_AFLAGS -o "$temp/a.out" -c -xassembler - <<-_EOF
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+ .type test, %function
+ .thumb_func
+ test:
+ mov r0, #0
+ badr lr, test
+ _EOF
+ disassembly="$($OBJDUMP -d "$temp/a.out")"
+
+ [[ $disassembly =~ 4:[[:space:]]*f2af\ 0e07 ]] && return 0
+
+ echo "Error: your assembler version produces buggy kernels:" >&2
+ read < <($AS --version) && echo "$REPLY" >&2
+ [[ $disassembly =~ 4:[[:space:]].*$ ]] && echo "${BASH_REMATCH[0]}" >&2 || echo "$disassembly" >&2
+ return 1
+}
+
+config="$(< .config)"
+[[ $config == *CONFIG_THUMB2_KERNEL=y* ]] && check_thumb2_address
+
+exit 0
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2] arm: detect buggy binutils when in thumb2 mode
@ 2017-11-23 11:50 ` Jason A. Donenfeld
0 siblings, 0 replies; 34+ messages in thread
From: Jason A. Donenfeld @ 2017-11-23 11:50 UTC (permalink / raw)
To: linux-arm-kernel
On older versions of binutils, \sym points to an aligned address. On
newer versions of binutils, \sym sometimes points to the unaligned thumb
address in certain circumstances. In order to homogenize this behavior,
rather than adding 1, we could simply OR in 1, so that already unaligned
instructions don't change. While that works, the downside is that we have
to add an `orr` instruction to a fast path. The assembler can't do this at
assemble time via "|1" because "invalid operands (.text and *ABS* sections)
for `|'". A better solution would be to have consistent binutils behavior,
but that ship has sailed.
So, this commit adds a detection mechanism, which began as a small thing
from Russell King that I then rewrote to use pure bash instead of
shelling out, so that it doesn't slow down the build process. The detection
mechanism _could_ be used to modify the assembly we generate, but for now
it's just being used to catch buggy binutils and abort the build process in
that case.
The rest of this commit message contains all of the relevant information
about the boot bug when compiled in thumb2 mode.
My tests concerned these versions:
broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
These produced the following code:
--- broken 2017-11-21 17:44:14.523416082 +0100
+++ working 2017-11-21 17:44:44.548461234 +0100
@@ -133,7 +133,7 @@
160: f01a 0ff0 tst.w sl, #240 ; 0xf0
164: d111 bne.n 18a <__sys_trace>
166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
- 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
+ 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
16e: bf38 it cc
170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
174: a902 add r1, sp, #8
The differing instruction corresponds with this actual line in
arch/arm/kernel/entry-common.S:
badr lr, ret_fast_syscall @ return address
Running the broken kernel results in a runtime OOPS with:
PC is at ret_fast_syscall+0x4/0x52
LR is at ret_fast_syscall+0x2/0x52
The disassembly of that function for the crashing kernel is:
.text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C?j
.text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
.text:00000002
.text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA?o
.text:00000002 LDR.W R2, [R9,#8]
.text:00000006 CMP.W R2, #0xBF000000
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: nickc at redhat.com
Cc: stable at vger.kernel.org
---
Had the file mode wrong on the submission from a second ago, sorry about
that.
arch/arm/Makefile | 7 +++++--
arch/arm/tools/Makefile | 5 ++++-
arch/arm/tools/toolcheck | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 3 deletions(-)
create mode 100755 arch/arm/tools/toolcheck
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 80351e505fd5..bd4e248a7f8f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
archheaders:
$(Q)$(MAKE) $(build)=arch/arm/tools uapi
-archprepare:
+archprepare: toolcheck
$(Q)$(MAKE) $(build)=arch/arm/tools kapi
+toolcheck:
+ $(Q)$(MAKE) $(build)=arch/arm/tools $@
+
# Convert bzImage to zImage
bzImage: zImage
BOOT_TARGETS = zImage Image xipImage bootpImage uImage
INSTALL_TARGETS = zinstall uinstall install
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
bootpImage uImage: zImage
zImage: Image
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index ddb89a7db36f..0a283756f1c5 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
-PHONY += kapi uapi
+PHONY += kapi uapi toolcheck
kapi: $(kapi-hdrs-y) $(gen-y)
uapi: $(uapi-hdrs-y)
+toolcheck:
+ @'$(srctree)/$(src)/toolcheck'
+
# Create output directory if not already present
_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
$(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
new file mode 100755
index 000000000000..04fc44b750d2
--- /dev/null
+++ b/arch/arm/tools/toolcheck
@@ -0,0 +1,44 @@
+#!/bin/bash
+#
+# Copyright 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
+#
+
+set -e
+
+cleanup() {
+ [[ ! -d $temp ]] || rm -rf "$temp"
+ exit
+}
+trap cleanup INT TERM EXIT
+temp="$(mktemp -d)"
+
+check_thumb2_address() {
+ local disassembly
+
+ $CC $KBUILD_AFLAGS -o "$temp/a.out" -c -xassembler - <<-_EOF
+ .syntax unified
+ .thumb
+ .macro badr, reg, sym
+ adr \reg, \sym + 1
+ .endm
+
+ .type test, %function
+ .thumb_func
+ test:
+ mov r0, #0
+ badr lr, test
+ _EOF
+ disassembly="$($OBJDUMP -d "$temp/a.out")"
+
+ [[ $disassembly =~ 4:[[:space:]]*f2af\ 0e07 ]] && return 0
+
+ echo "Error: your assembler version produces buggy kernels:" >&2
+ read < <($AS --version) && echo "$REPLY" >&2
+ [[ $disassembly =~ 4:[[:space:]].*$ ]] && echo "${BASH_REMATCH[0]}" >&2 || echo "$disassembly" >&2
+ return 1
+}
+
+config="$(< .config)"
+[[ $config == *CONFIG_THUMB2_KERNEL=y* ]] && check_thumb2_address
+
+exit 0
--
2.15.0
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v2] arm: detect buggy binutils when in thumb2 mode
2017-11-23 11:50 ` Jason A. Donenfeld
@ 2017-11-23 12:01 ` Martin Storsjö
-1 siblings, 0 replies; 34+ messages in thread
From: Martin Storsjö @ 2017-11-23 12:01 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: nickc, binutils, linux-arm-kernel, linux, linux-kernel, stable
On Thu, 23 Nov 2017, Jason A. Donenfeld wrote:
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in certain circumstances. In order to homogenize this behavior,
> rather than adding 1, we could simply OR in 1, so that already unaligned
> instructions don't change. While that works, the downside is that we have
> to add an `orr` instruction to a fast path. The assembler can't do this at
> assemble time via "|1" because "invalid operands (.text and *ABS* sections)
> for `|'". A better solution would be to have consistent binutils behavior,
> but that ship has sailed.
>
> So, this commit adds a detection mechanism, which began as a small thing
> from Russell King that I then rewrote to use pure bash instead of
> shelling out, so that it doesn't slow down the build process. The detection
> mechanism _could_ be used to modify the assembly we generate, but for now
> it's just being used to catch buggy binutils and abort the build process in
> that case.
>
> The rest of this commit message contains all of the relevant information
> about the boot bug when compiled in thumb2 mode.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
FWIW, this issue stems from this change:
https://sourceware.org/bugzilla/show_bug.cgi?id=21458
The same issue caused problems in libavcodec as well, where we chose to
work around the issue in this fashion:
https://git.libav.org/?p=libav.git;a=commitdiff;h=9dde6ab06c48f9447cd16f39bee33569cddb7be4;hp=547db1eaecd597031165a2bf637acaaacde52788
Related debian bug report, with a different workaround:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870622
(In libav, we chose the workaround since the .eqv one suggested in the
debian bug report didn't really work well with assemblers for other
platforms.)
// Martin
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2] arm: detect buggy binutils when in thumb2 mode
@ 2017-11-23 12:01 ` Martin Storsjö
0 siblings, 0 replies; 34+ messages in thread
From: Martin Storsjö @ 2017-11-23 12:01 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 23 Nov 2017, Jason A. Donenfeld wrote:
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in certain circumstances. In order to homogenize this behavior,
> rather than adding 1, we could simply OR in 1, so that already unaligned
> instructions don't change. While that works, the downside is that we have
> to add an `orr` instruction to a fast path. The assembler can't do this at
> assemble time via "|1" because "invalid operands (.text and *ABS* sections)
> for `|'". A better solution would be to have consistent binutils behavior,
> but that ship has sailed.
>
> So, this commit adds a detection mechanism, which began as a small thing
> from Russell King that I then rewrote to use pure bash instead of
> shelling out, so that it doesn't slow down the build process. The detection
> mechanism _could_ be used to modify the assembly we generate, but for now
> it's just being used to catch buggy binutils and abort the build process in
> that case.
>
> The rest of this commit message contains all of the relevant information
> about the boot bug when compiled in thumb2 mode.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
FWIW, this issue stems from this change:
https://sourceware.org/bugzilla/show_bug.cgi?id=21458
The same issue caused problems in libavcodec as well, where we chose to
work around the issue in this fashion:
https://git.libav.org/?p=libav.git;a=commitdiff;h=9dde6ab06c48f9447cd16f39bee33569cddb7be4;hp=547db1eaecd597031165a2bf637acaaacde52788
Related debian bug report, with a different workaround:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870622
(In libav, we chose the workaround since the .eqv one suggested in the
debian bug report didn't really work well with assemblers for other
platforms.)
// Martin
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-23 10:47 ` Jason A. Donenfeld
@ 2017-11-23 14:02 ` Russell King - ARM Linux
-1 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-23 14:02 UTC (permalink / raw)
To: nickc; +Cc: Jason A. Donenfeld, binutils, stable, linux-arm-kernel, LKML
On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
> Hello Nick & Binutils developers,
>
> It would appear that recent changes in the binutils assembler (perhaps
> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
> the kernel when compiled in thumb2 mode. We currently do not have a
> way of working around your breaking changes without adding additional
> runtime instructions, which isn't acceptable for us. Details are
> included in the thread below.
Hi Nick,
I have to ask why it was thought a good idea to change the behaviour
of the assembler's "adr" pseudo-instruction after it's had the existing
behaviour for such a long time.
I see in the bug report https://sourceware.org/bugzilla/show_bug.cgi?id=21458
that guidance was sort from ARM Ltd, but none was forthcoming - which
implies that there was little technical input to make the change.
Given that the change has been known to break at least three programs
(the Linux kernel, libavcodec and openssl), that there's no technical
reason to make the change, and that it introduces inconsistency in
the assembler, is there enough reason to get the change at least
partially removed - restoring the long-standing "adr" behaviour?
The inconsistency is introduced in that "adr" now behaves differently
depending on whether the symbol is marked as a thumb function (which
requires an explicit pseudo-op) or not. This means that either we
need additional labels that are not marked as a thumb function for use
with "adr" or we need to mark _every_ symbol in thumb code that is used
with "adr" with a .thumb_func annotation, including the numeric local
labels.
This makes it much harder to review patches for projects and ensure
that they are correct as it means that reviewers now need to do detailed
in-depth analysis of the code after /any/ patch that uses "adr" has been
applied. Given that the failure is will only be seen at runtime, this
is particularly bad.
>
> Thanks,
> Jason
>
> Forwarded conversation
> Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
> ------------------------
>
> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Date: Tue, Nov 21, 2017 at 6:27 PM
> To: linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org
> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, stable@vger.kernel.org
>
>
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in mysterious and buggy circumstances. In order to homogenize
> this behavior, rather than adding 1, we simply OR in 1, so that already
> unaligned instructions don't change. This fix is required for a
> pedestrian THUMB2_KERNEL to boot without crashing when built with
> non-old binutils.
>
> While it works, the downside is that we have to add an `orr` instruction
> to a fast path. The assembler can't do this at assemble time via "|1"
> because "invalid operands (.text and *ABS* sections) for `|'", so we're
> forced to do this. A better solution would be to have consistent
> binutils behavior, or to have some kind of \sym feature detection that
> won't turn into a maze of version comparisons. However, it's at the
> moment unclear how to achieve this.
>
> The rest of this commit message contains all of the relevant
> information.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> These produced the following code:
> --- broken 2017-11-21 17:44:14.523416082 +0100
> +++ working 2017-11-21 17:44:44.548461234 +0100
> @@ -133,7 +133,7 @@
> 160: f01a 0ff0 tst.w sl, #240 ; 0xf0
> 164: d111 bne.n 18a <__sys_trace>
> 166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
> - 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
> + 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
> 16e: bf38 it cc
> 170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
> 174: a902 add r1, sp, #8
>
> The differing instruction corresponds with this actual line in
> arch/arm/kernel/entry-common.S:
> badr lr, ret_fast_syscall @ return address
>
> Running the broken kernel results in a runtime OOPS with:
> PC is at ret_fast_syscall+0x4/0x52
> LR is at ret_fast_syscall+0x2/0x52
>
> The disassembly of that function for the crashing kernel is:
> .text:00000000 ret_fast_syscall ; CODE XREF:
> sys_syscall+1C↓j
> .text:00000000 CPSID I ; jumptable
> 00000840 cases 15,18-376
> .text:00000002
> .text:00000002 loc_2 ; DATA XREF:
> sys_syscall-6BA↓o
> .text:00000002 LDR.W R2, [R9,#8]
> .text:00000006 CMP.W R2, #0xBF000000
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: stable@vger.kernel.org
> ---
> arch/arm/include/asm/assembler.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index ad301f107dd2..c62a3b6b0a3e 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -194,10 +194,9 @@
> */
> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> .macro badr\c, rd, sym
> -#ifdef CONFIG_THUMB2_KERNEL
> - adr\c \rd, \sym + 1
> -#else
> adr\c \rd, \sym
> +#ifdef CONFIG_THUMB2_KERNEL
> + orr\c \rd, \rd, 1
> #endif
> .endm
> .endr
> --
> 2.15.0
>
>
> ----------
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Date: Tue, Nov 21, 2017 at 6:38 PM
> To: "Jason A. Donenfeld" <Jason@zx2c4.com>, Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
> stable@vger.kernel.org
>
>
> As it just seems to be a limited range of binutils versions that are
> affected, I'd rather not impact the kernel fast-paths with extra
> cycles just because binutils decided to change behaviour. I'd prefer
> to inform people about the problem and get them to change to a non-
> buggy binutils.
>
> This seems to be the second binutils bug that's biting us within the
> last month... what's going on with binutils QA?
>
> arch/arm/Makefile | 7 +++++--
> arch/arm/tools/Makefile | 5 ++++-
> arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 1cfac5119545..9e70d0435121 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
> archheaders:
> $(Q)$(MAKE) $(build)=arch/arm/tools uapi
>
> -archprepare:
> +archprepare: toolcheck
> $(Q)$(MAKE) $(build)=arch/arm/tools kapi
>
> +toolcheck:
> + $(Q)$(MAKE) $(build)=arch/arm/tools $@
> +
> # Convert bzImage to zImage
> bzImage: zImage
>
> BOOT_TARGETS = zImage Image xipImage bootpImage uImage
> INSTALL_TARGETS = zinstall uinstall install
>
> -PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
> +PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
>
> bootpImage uImage: zImage
> zImage: Image
> diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
> index ddb89a7db36f..fa77351ccefd 100644
> --- a/arch/arm/tools/Makefile
> +++ b/arch/arm/tools/Makefile
> @@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
>
> targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
>
> -PHONY += kapi uapi
> +PHONY += kapi uapi toolcheck
>
> kapi: $(kapi-hdrs-y) $(gen-y)
>
> uapi: $(uapi-hdrs-y)
>
> +toolcheck:
> + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
> +
> # Create output directory if not already present
> _dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
> $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
> diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
> index e69de29bb2d1..97bbeeb691da 100644
> --- a/arch/arm/tools/toolcheck
> +++ b/arch/arm/tools/toolcheck
> @@ -0,0 +1,24 @@
> +#!/bin/sh -ex
> +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
> + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> + .syntax unified
> + .thumb
> + .macro badr, reg, sym
> + adr \reg, \sym + 1
> + .endm
> +
> +test:
> + mov r0, #0
> + badr lr, test
> +EOF
> + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> + echo "Error: your assembler version produces buggy kernels" >&2
> + $AS --version | head -n1 >&2
> + rm $tmp/*.o
> + rmdir $tmp
> + exit 1
> + fi
> + rm $tmp/*.o
> + rmdir $tmp
> +fi
>
> ----------
> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Date: Tue, Nov 21, 2017 at 6:46 PM
> To: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>,
> linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
> stable@vger.kernel.org
>
>
> Hi Russell,
>
> This doesn't actually catch the issues. In the buggy binutils, it
> appears that sometimes adr grabs the right symbol and sometimes it
> doesn't. I'm not yet able to figure out a minimal condition for it
> going one way or the other.
>
> Jason
>
> ----------
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Date: Thu, Nov 23, 2017 at 11:35 AM
> To: "Jason A. Donenfeld" <Jason@zx2c4.com>
> Cc: Will Deacon <will.deacon@arm.com>,
> linux-arm-kernel@lists.infradead.org, lkml@vger.kernel.org,
> stable@vger.kernel.org
>
>
> On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> > On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > What if we locate the "badr" instruction to the same offset - does
> > > that trigger the binutils bug? Note that the grep expression will
> > > need updating...
> >
> > Nope, this too does not reproduce it. I'm having a bit of trouble
> > making a minimal test case to reproduce it. But I can reproduce it
> > everytime by simply assembling the file in question using that
> > binutils.
>
> If it's that hard to reproduce it, it makes me wonder if it's being
> caused by some memory allocation being re-used without full
> initialisation, and it's reading stale data.
>
> We can't easily build entry-common.o and check it for the problem as the
> position of the "local_restart" code depends on various configuration
> options.
>
> I found this URL:
>
> https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
>
> and if you search down to around "line 8358", which is in do_adr(),
> there is this new code added:
>
> if (inst.reloc.exp.X_op == O_symbol
> && inst.reloc.exp.X_add_symbol != NULL
> && S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
> && THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
> inst.reloc.exp.X_add_number += 1;
>
> which would account for the issue you're seeing.
>
> Given that this change breaks openssl, and breaks the kernel, and
> this behaviour is something that we've come to rely upon in the
> kernel since T2 was introduced, and there's no way around it without
> adding additional instructions, I have to ask what the hell binutils
> people think they are doing changing the behaviour of the assembler
> in such a gratuitous way, and how they think that users of their
> crapware are going to be able to write code that assembles correctly
> on both pre-2.29 assemblers and post-2.29 assemblers.
>
> Sorry, but gratuitous changes like this in the toolchain really
> annoy me, and just give me more reason to stick with my old known
> working versions (binutils 2.25, gcc 4.7.4!) rather than move
> forward and then not know whether bugs are due to crappy toolchains
> or really something wrong in the program.
>
> binutils people need to realise that what they offer is an interface
> for converting assembly code into opcodes and if they change the
> translation of that in a visible way, people are going to get
> annoyed - just like if we in the kernel change the kernel's user
> visible API.
>
> IMHO, binutils should have exactly the same rules - if a change causes
> a regression for a user, the change is wrong and should be reverted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-23 14:02 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2017-11-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
> Hello Nick & Binutils developers,
>
> It would appear that recent changes in the binutils assembler (perhaps
> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
> the kernel when compiled in thumb2 mode. We currently do not have a
> way of working around your breaking changes without adding additional
> runtime instructions, which isn't acceptable for us. Details are
> included in the thread below.
Hi Nick,
I have to ask why it was thought a good idea to change the behaviour
of the assembler's "adr" pseudo-instruction after it's had the existing
behaviour for such a long time.
I see in the bug report https://sourceware.org/bugzilla/show_bug.cgi?id=21458
that guidance was sort from ARM Ltd, but none was forthcoming - which
implies that there was little technical input to make the change.
Given that the change has been known to break at least three programs
(the Linux kernel, libavcodec and openssl), that there's no technical
reason to make the change, and that it introduces inconsistency in
the assembler, is there enough reason to get the change at least
partially removed - restoring the long-standing "adr" behaviour?
The inconsistency is introduced in that "adr" now behaves differently
depending on whether the symbol is marked as a thumb function (which
requires an explicit pseudo-op) or not. This means that either we
need additional labels that are not marked as a thumb function for use
with "adr" or we need to mark _every_ symbol in thumb code that is used
with "adr" with a .thumb_func annotation, including the numeric local
labels.
This makes it much harder to review patches for projects and ensure
that they are correct as it means that reviewers now need to do detailed
in-depth analysis of the code after /any/ patch that uses "adr" has been
applied. Given that the failure is will only be seen at runtime, this
is particularly bad.
>
> Thanks,
> Jason
>
> Forwarded conversation
> Subject: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
> ------------------------
>
> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Date: Tue, Nov 21, 2017 at 6:27 PM
> To: linux at armlinux.org.uk, linux-arm-kernel at lists.infradead.org
> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, stable at vger.kernel.org
>
>
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in mysterious and buggy circumstances. In order to homogenize
> this behavior, rather than adding 1, we simply OR in 1, so that already
> unaligned instructions don't change. This fix is required for a
> pedestrian THUMB2_KERNEL to boot without crashing when built with
> non-old binutils.
>
> While it works, the downside is that we have to add an `orr` instruction
> to a fast path. The assembler can't do this at assemble time via "|1"
> because "invalid operands (.text and *ABS* sections) for `|'", so we're
> forced to do this. A better solution would be to have consistent
> binutils behavior, or to have some kind of \sym feature detection that
> won't turn into a maze of version comparisons. However, it's at the
> moment unclear how to achieve this.
>
> The rest of this commit message contains all of the relevant
> information.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> These produced the following code:
> --- broken 2017-11-21 17:44:14.523416082 +0100
> +++ working 2017-11-21 17:44:44.548461234 +0100
> @@ -133,7 +133,7 @@
> 160: f01a 0ff0 tst.w sl, #240 ; 0xf0
> 164: d111 bne.n 18a <__sys_trace>
> 166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
> - 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
> + 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
> 16e: bf38 it cc
> 170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
> 174: a902 add r1, sp, #8
>
> The differing instruction corresponds with this actual line in
> arch/arm/kernel/entry-common.S:
> badr lr, ret_fast_syscall @ return address
>
> Running the broken kernel results in a runtime OOPS with:
> PC is at ret_fast_syscall+0x4/0x52
> LR is at ret_fast_syscall+0x2/0x52
>
> The disassembly of that function for the crashing kernel is:
> .text:00000000 ret_fast_syscall ; CODE XREF:
> sys_syscall+1C?j
> .text:00000000 CPSID I ; jumptable
> 00000840 cases 15,18-376
> .text:00000002
> .text:00000002 loc_2 ; DATA XREF:
> sys_syscall-6BA?o
> .text:00000002 LDR.W R2, [R9,#8]
> .text:00000006 CMP.W R2, #0xBF000000
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: stable at vger.kernel.org
> ---
> arch/arm/include/asm/assembler.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index ad301f107dd2..c62a3b6b0a3e 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -194,10 +194,9 @@
> */
> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> .macro badr\c, rd, sym
> -#ifdef CONFIG_THUMB2_KERNEL
> - adr\c \rd, \sym + 1
> -#else
> adr\c \rd, \sym
> +#ifdef CONFIG_THUMB2_KERNEL
> + orr\c \rd, \rd, 1
> #endif
> .endm
> .endr
> --
> 2.15.0
>
>
> ----------
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Date: Tue, Nov 21, 2017 at 6:38 PM
> To: "Jason A. Donenfeld" <Jason@zx2c4.com>, Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
> stable at vger.kernel.org
>
>
> As it just seems to be a limited range of binutils versions that are
> affected, I'd rather not impact the kernel fast-paths with extra
> cycles just because binutils decided to change behaviour. I'd prefer
> to inform people about the problem and get them to change to a non-
> buggy binutils.
>
> This seems to be the second binutils bug that's biting us within the
> last month... what's going on with binutils QA?
>
> arch/arm/Makefile | 7 +++++--
> arch/arm/tools/Makefile | 5 ++++-
> arch/arm/tools/toolcheck | 24 ++++++++++++++++++++++++
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 1cfac5119545..9e70d0435121 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -319,16 +319,19 @@ all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
> archheaders:
> $(Q)$(MAKE) $(build)=arch/arm/tools uapi
>
> -archprepare:
> +archprepare: toolcheck
> $(Q)$(MAKE) $(build)=arch/arm/tools kapi
>
> +toolcheck:
> + $(Q)$(MAKE) $(build)=arch/arm/tools $@
> +
> # Convert bzImage to zImage
> bzImage: zImage
>
> BOOT_TARGETS = zImage Image xipImage bootpImage uImage
> INSTALL_TARGETS = zinstall uinstall install
>
> -PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
> +PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS) toolcheck
>
> bootpImage uImage: zImage
> zImage: Image
> diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
> index ddb89a7db36f..fa77351ccefd 100644
> --- a/arch/arm/tools/Makefile
> +++ b/arch/arm/tools/Makefile
> @@ -23,12 +23,15 @@ uapi-hdrs-y += $(uapi)/unistd-eabi.h
>
> targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y) $(uapi-hdrs-y))
>
> -PHONY += kapi uapi
> +PHONY += kapi uapi toolcheck
>
> kapi: $(kapi-hdrs-y) $(gen-y)
>
> uapi: $(uapi-hdrs-y)
>
> +toolcheck:
> + @$(CONFIG_SHELL) '$(srctree)/$(src)/toolcheck'
> +
> # Create output directory if not already present
> _dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') \
> $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')
> diff --git a/arch/arm/tools/toolcheck b/arch/arm/tools/toolcheck
> index e69de29bb2d1..97bbeeb691da 100644
> --- a/arch/arm/tools/toolcheck
> +++ b/arch/arm/tools/toolcheck
> @@ -0,0 +1,24 @@
> +#!/bin/sh -ex
> +if grep -q 'CONFIG_THUMB2_KERNEL=y' .config; then
> + tmp=$(mktemp -d /tmp/binutils-test.XXXXXXXXXX)
> + cat <<EOF | $AS $ASFLAGS -o $tmp/test.o
> + .syntax unified
> + .thumb
> + .macro badr, reg, sym
> + adr \reg, \sym + 1
> + .endm
> +
> +test:
> + mov r0, #0
> + badr lr, test
> +EOF
> + if ! $OBJDUMP -d $tmp/test.o | grep -q '4:\s*f2af 0e07'; then
> + echo "Error: your assembler version produces buggy kernels" >&2
> + $AS --version | head -n1 >&2
> + rm $tmp/*.o
> + rmdir $tmp
> + exit 1
> + fi
> + rm $tmp/*.o
> + rmdir $tmp
> +fi
>
> ----------
> From: Jason A. Donenfeld <Jason@zx2c4.com>
> Date: Tue, Nov 21, 2017 at 6:46 PM
> To: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>,
> linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
> stable at vger.kernel.org
>
>
> Hi Russell,
>
> This doesn't actually catch the issues. In the buggy binutils, it
> appears that sometimes adr grabs the right symbol and sometimes it
> doesn't. I'm not yet able to figure out a minimal condition for it
> going one way or the other.
>
> Jason
>
> ----------
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Date: Thu, Nov 23, 2017 at 11:35 AM
> To: "Jason A. Donenfeld" <Jason@zx2c4.com>
> Cc: Will Deacon <will.deacon@arm.com>,
> linux-arm-kernel at lists.infradead.org, lkml at vger.kernel.org,
> stable at vger.kernel.org
>
>
> On Thu, Nov 23, 2017 at 12:34:08AM +0100, Jason A. Donenfeld wrote:
> > On Tue, Nov 21, 2017 at 6:49 PM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > What if we locate the "badr" instruction to the same offset - does
> > > that trigger the binutils bug? Note that the grep expression will
> > > need updating...
> >
> > Nope, this too does not reproduce it. I'm having a bit of trouble
> > making a minimal test case to reproduce it. But I can reproduce it
> > everytime by simply assembling the file in question using that
> > binutils.
>
> If it's that hard to reproduce it, it makes me wonder if it's being
> caused by some memory allocation being re-used without full
> initialisation, and it's reading stale data.
>
> We can't easily build entry-common.o and check it for the problem as the
> position of the "local_restart" code depends on various configuration
> options.
>
> I found this URL:
>
> https://fossies.org/diffs/binutils/2.28_vs_2.29/gas/config/tc-arm.c-diff.html
>
> and if you search down to around "line 8358", which is in do_adr(),
> there is this new code added:
>
> if (inst.reloc.exp.X_op == O_symbol
> && inst.reloc.exp.X_add_symbol != NULL
> && S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
> && THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
> inst.reloc.exp.X_add_number += 1;
>
> which would account for the issue you're seeing.
>
> Given that this change breaks openssl, and breaks the kernel, and
> this behaviour is something that we've come to rely upon in the
> kernel since T2 was introduced, and there's no way around it without
> adding additional instructions, I have to ask what the hell binutils
> people think they are doing changing the behaviour of the assembler
> in such a gratuitous way, and how they think that users of their
> crapware are going to be able to write code that assembles correctly
> on both pre-2.29 assemblers and post-2.29 assemblers.
>
> Sorry, but gratuitous changes like this in the toolchain really
> annoy me, and just give me more reason to stick with my old known
> working versions (binutils 2.25, gcc 4.7.4!) rather than move
> forward and then not know whether bugs are due to crappy toolchains
> or really something wrong in the program.
>
> binutils people need to realise that what they offer is an interface
> for converting assembly code into opcodes and if they change the
> translation of that in a visible way, people are going to get
> annoyed - just like if we in the kernel change the kernel's user
> visible API.
>
> IMHO, binutils should have exactly the same rules - if a change causes
> a regression for a user, the change is wrong and should be reverted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-23 14:02 ` Russell King - ARM Linux
(?)
@ 2017-11-23 14:26 ` Ard Biesheuvel
-1 siblings, 0 replies; 34+ messages in thread
From: Ard Biesheuvel @ 2017-11-23 14:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: nickc, linux-arm-kernel, Jason A. Donenfeld, binutils, stable, LKML
On 23 November 2017 at 14:02, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
>> Hello Nick & Binutils developers,
>>
>> It would appear that recent changes in the binutils assembler (perhaps
>> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
>> the kernel when compiled in thumb2 mode. We currently do not have a
>> way of working around your breaking changes without adding additional
>> runtime instructions, which isn't acceptable for us. Details are
>> included in the thread below.
>
> Hi Nick,
>
> I have to ask why it was thought a good idea to change the behaviour
> of the assembler's "adr" pseudo-instruction after it's had the existing
> behaviour for such a long time.
>
I think part of the confusion comes from the fact that ADR is no
longer a pseudo-instruction on Thumb2, and can be used to create
cross-section symbol references that are fixed up by the linker (using
a dedicated relocation type)
So before the change, we were in the situation where ADR behaved
differently when used on symbols, depending on whether they were
defined in the same section or not:
- cross section symbol references are fixed up by the linker, and do
take the Thumb bit into account for function symbols,
- local symbol references and label references are not fixed up at
all, regardless of their type annotation.
Note that external symbol references are hardly ever used, given that
they don't work in ARM mode (since it is a pseudo op there), so in the
kernel, we only care about local symbol references and label
references.
After the change, internal symbol references behave differently, but
label references behave the same. So the uniform behavior we care
about and rely on is no longer there, and even worse, we cannot deal
with this in the code because we cannot detect which binutils version
we are using without intrusive workarounds)
--
Ard.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-23 14:26 ` Ard Biesheuvel
0 siblings, 0 replies; 34+ messages in thread
From: Ard Biesheuvel @ 2017-11-23 14:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: nickc, linux-arm-kernel, Jason A. Donenfeld, binutils, stable, LKML
On 23 November 2017 at 14:02, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
>> Hello Nick & Binutils developers,
>>
>> It would appear that recent changes in the binutils assembler (perhaps
>> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
>> the kernel when compiled in thumb2 mode. We currently do not have a
>> way of working around your breaking changes without adding additional
>> runtime instructions, which isn't acceptable for us. Details are
>> included in the thread below.
>
> Hi Nick,
>
> I have to ask why it was thought a good idea to change the behaviour
> of the assembler's "adr" pseudo-instruction after it's had the existing
> behaviour for such a long time.
>
I think part of the confusion comes from the fact that ADR is no
longer a pseudo-instruction on Thumb2, and can be used to create
cross-section symbol references that are fixed up by the linker (using
a dedicated relocation type)
So before the change, we were in the situation where ADR behaved
differently when used on symbols, depending on whether they were
defined in the same section or not:
- cross section symbol references are fixed up by the linker, and do
take the Thumb bit into account for function symbols,
- local symbol references and label references are not fixed up at
all, regardless of their type annotation.
Note that external symbol references are hardly ever used, given that
they don't work in ARM mode (since it is a pseudo op there), so in the
kernel, we only care about local symbol references and label
references.
After the change, internal symbol references behave differently, but
label references behave the same. So the uniform behavior we care
about and rely on is no longer there, and even worse, we cannot deal
with this in the code because we cannot detect which binutils version
we are using without intrusive workarounds)
--
Ard.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
@ 2017-11-23 14:26 ` Ard Biesheuvel
0 siblings, 0 replies; 34+ messages in thread
From: Ard Biesheuvel @ 2017-11-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel
On 23 November 2017 at 14:02, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Nov 23, 2017 at 11:47:56AM +0100, Jason A. Donenfeld wrote:
>> Hello Nick & Binutils developers,
>>
>> It would appear that recent changes in the binutils assembler (perhaps
>> 52a86f843b6dee1de9977293da9786649b146b05? perhaps not?) have broken
>> the kernel when compiled in thumb2 mode. We currently do not have a
>> way of working around your breaking changes without adding additional
>> runtime instructions, which isn't acceptable for us. Details are
>> included in the thread below.
>
> Hi Nick,
>
> I have to ask why it was thought a good idea to change the behaviour
> of the assembler's "adr" pseudo-instruction after it's had the existing
> behaviour for such a long time.
>
I think part of the confusion comes from the fact that ADR is no
longer a pseudo-instruction on Thumb2, and can be used to create
cross-section symbol references that are fixed up by the linker (using
a dedicated relocation type)
So before the change, we were in the situation where ADR behaved
differently when used on symbols, depending on whether they were
defined in the same section or not:
- cross section symbol references are fixed up by the linker, and do
take the Thumb bit into account for function symbols,
- local symbol references and label references are not fixed up at
all, regardless of their type annotation.
Note that external symbol references are hardly ever used, given that
they don't work in ARM mode (since it is a pseudo op there), so in the
kernel, we only care about local symbol references and label
references.
After the change, internal symbol references behave differently, but
label references behave the same. So the uniform behavior we care
about and rely on is no longer there, and even worse, we cannot deal
with this in the code because we cannot detect which binutils version
we are using without intrusive workarounds)
--
Ard.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2017-11-21 17:27 ` Jason A. Donenfeld
(?)
(?)
@ 2018-01-16 8:43 ` Chen-Yu Tsai
-1 siblings, 0 replies; 34+ messages in thread
From: Chen-Yu Tsai @ 2018-01-16 8:43 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: Russell King, linux-arm-kernel, lkml, stable
On Wed, Nov 22, 2017 at 1:27 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On older versions of binutils, \sym points to an aligned address. On
> newer versions of binutils, \sym sometimes points to the unaligned thumb
> address in mysterious and buggy circumstances. In order to homogenize
> this behavior, rather than adding 1, we simply OR in 1, so that already
> unaligned instructions don't change. This fix is required for a
> pedestrian THUMB2_KERNEL to boot without crashing when built with
> non-old binutils.
>
> While it works, the downside is that we have to add an `orr` instruction
> to a fast path. The assembler can't do this at assemble time via "|1"
> because "invalid operands (.text and *ABS* sections) for `|'", so we're
> forced to do this. A better solution would be to have consistent
> binutils behavior, or to have some kind of \sym feature detection that
> won't turn into a maze of version comparisons. However, it's at the
> moment unclear how to achieve this.
>
> The rest of this commit message contains all of the relevant
> information.
>
> My tests concerned these versions:
> broken: GNU ld (Gentoo 2.29.1 p3) 2.29.1
> working: GNU ld (GNU Binutils for Ubuntu) 2.26.1
>
> These produced the following code:
> --- broken 2017-11-21 17:44:14.523416082 +0100
> +++ working 2017-11-21 17:44:44.548461234 +0100
> @@ -133,7 +133,7 @@
> 160: f01a 0ff0 tst.w sl, #240 ; 0xf0
> 164: d111 bne.n 18a <__sys_trace>
> 166: f5b7 7fc8 cmp.w r7, #400 ; 0x190
> - 16a: f2af 1e6a subw lr, pc, #362 ; 0x16a
> + 16a: f2af 1e6b subw lr, pc, #363 ; 0x16b
> 16e: bf38 it cc
> 170: f858 f027 ldrcc.w pc, [r8, r7, lsl #2]
> 174: a902 add r1, sp, #8
>
> The differing instruction corresponds with this actual line in
> arch/arm/kernel/entry-common.S:
> badr lr, ret_fast_syscall @ return address
>
> Running the broken kernel results in a runtime OOPS with:
> PC is at ret_fast_syscall+0x4/0x52
> LR is at ret_fast_syscall+0x2/0x52
>
> The disassembly of that function for the crashing kernel is:
> .text:00000000 ret_fast_syscall ; CODE XREF: sys_syscall+1C↓j
> .text:00000000 CPSID I ; jumptable 00000840 cases 15,18-376
> .text:00000002
> .text:00000002 loc_2 ; DATA XREF: sys_syscall-6BA↓o
> .text:00000002 LDR.W R2, [R9,#8]
> .text:00000006 CMP.W R2, #0xBF000000
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: stable@vger.kernel.org
FWIW, this patch fixes things for me. Never occurred to me that
it was binutils that was at fault.
Tested-by: Chen-Yu Tsai <wens@csie.org>
with
$ arm-linux-gnueabihf-ld -v
GNU ld (GNU Binutils for Debian) 2.29.1
$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/7/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian
7.2.0-11' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libquadmath --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabihf
--program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-11)
ChenYu
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <254af731-459b-1f1d-2d93-27c5a91e7bfb@redhat.com>
@ 2018-05-31 21:16 ` Romain Naour
2018-06-01 8:28 ` Christophe PRIOUZEAU
0 siblings, 1 reply; 34+ messages in thread
From: Romain Naour @ 2018-05-31 21:16 UTC (permalink / raw)
To: buildroot
Hi Nick,
Le 31/05/2018 ? 15:00, Nick Clifton a ?crit?:
> Hi Romain,
>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
>>
>> What's the status of this bug?
>
> It was sidelined. :-( Sorry.
No problem :-)
>
>> Some users reported a runtime issue with the linux kernel boot for Cortex-M
>> target: https://bugs.buildroot.org/show_bug.cgi?id=11051
>
> I think that part of the problem is that the kernel people are
> asking for the (adr affecting part of the) patch to be reverted,
> but they have not suggested a way to address the issue raised in
> the PR. (From comment #6 onwards).
Yes, but it's a very difficult topic.
Did you have some feedback from ARM ?
>
> One thing that did occur to me is that the adr handling code
> in the assembler does not check to see if the bottom bit has
> already been set, so maybe this is part of the problem. Are
> you able to test out an assembler patch and see if it makes
> a difference ?
I'm not able to test this patch but I'm adding Christophe Priouzeau in Cc.
He use a stm32f429 system.
Christophe, it would be great if you can test this patch with your toolchain
based on Binutils 2.29.
>
> diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
> index dbaf1627bb..c682ceabd3 100644
> --- a/gas/config/tc-arm.c
> +++ b/gas/config/tc-arm.c
> @@ -8423,7 +8423,7 @@ do_adr (void)
> && inst.reloc.exp.X_add_symbol != NULL
> && S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
> && THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
> - inst.reloc.exp.X_add_number += 1;
> + inst.reloc.exp.X_add_number |= 1;
> }
>
> /* This is a pseudo-op of the form "adrl rd, label" to be converted
>
> If that does not help, then I think that the only thing to do is
> to add a command line option to control the behaviour of the ADR
> pseudo-op and a configure time switch to set the default for this
> option.
Ok, let's see the test result.
Thanks for your time,
Romain
>
> Cheers
> Nick
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2018-05-31 21:16 ` [Buildroot] " Romain Naour
@ 2018-06-01 8:28 ` Christophe PRIOUZEAU
[not found] ` <2a8151c1-644e-a6b0-9a21-2c570ac7000b@redhat.com>
0 siblings, 1 reply; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-01 8:28 UTC (permalink / raw)
To: buildroot
Hi,
On 05/31/2018 11:16 PM, Romain Naour wrote:
> Hi Nick,
>
> Le 31/05/2018 ? 15:00, Nick Clifton a ?crit?:
>> Hi Romain,
>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
>>> What's the status of this bug?
>> It was sidelined. :-( Sorry.
> No problem :-)
>
>>> Some users reported a runtime issue with the linux kernel boot for Cortex-M
>>> target: https://bugs.buildroot.org/show_bug.cgi?id=11051
>> I think that part of the problem is that the kernel people are
>> asking for the (adr affecting part of the) patch to be reverted,
>> but they have not suggested a way to address the issue raised in
>> the PR. (From comment #6 onwards).
> Yes, but it's a very difficult topic.
> Did you have some feedback from ARM ?
>
>> One thing that did occur to me is that the adr handling code
>> in the assembler does not check to see if the bottom bit has
>> already been set, so maybe this is part of the problem. Are
>> you able to test out an assembler patch and see if it makes
>> a difference ?
> I'm not able to test this patch but I'm adding Christophe Priouzeau in Cc.
> He use a stm32f429 system.
>
> Christophe, it would be great if you can test this patch with your toolchain
> based on Binutils 2.29.
I have made the test on buildroot 2018.05-rc3 with bintutils 2.29.1 and
2.30,
for the two test my boot failed. The proposition of correction doesn't work.
Thanks
>> diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
>> index dbaf1627bb..c682ceabd3 100644
>> --- a/gas/config/tc-arm.c
>> +++ b/gas/config/tc-arm.c
>> @@ -8423,7 +8423,7 @@ do_adr (void)
>> && inst.reloc.exp.X_add_symbol != NULL
>> && S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
>> && THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
>> - inst.reloc.exp.X_add_number += 1;
>> + inst.reloc.exp.X_add_number |= 1;
>> }
>>
>> /* This is a pseudo-op of the form "adrl rd, label" to be converted
>>
>> If that does not help, then I think that the only thing to do is
>> to add a command line option to control the behaviour of the ADR
>> pseudo-op and a configure time switch to set the default for this
>> option.
> Ok, let's see the test result.
>
> Thanks for your time,
> Romain
>
>> Cheers
>> Nick
>>
If you want to? do more test, there is no problem.
Thanks for your help
Regards
Christophe
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <2a8151c1-644e-a6b0-9a21-2c570ac7000b@redhat.com>
@ 2018-06-05 8:52 ` Christophe PRIOUZEAU
[not found] ` <ec2b0134-6c4a-53ff-4ae2-69c3f0646ded@redhat.com>
0 siblings, 1 reply; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-05 8:52 UTC (permalink / raw)
To: buildroot
Hi Nick,
On 06/04/2018 04:13 PM, Nick Clifton wrote:
> Hi Christophe,
>
>> I have made the test on buildroot 2018.05-rc3 with bintutils 2.29.1 and
>> 2.30,
>> for the two test my boot failed. The proposition of correction doesn't work.
> Ho hum. OK, please could you try out this attached patch instead. It is part
> of a larger patch to allow the behaviour of the assembler to be controlled by
> a command line option, whose default is set at configure time. I just want to
> be sure that the "ADR-does-NOT-set-interworking" default option actually does
> work before I complete the rest of the patch.
>
> Cheers
> Nick
>
>
I have made several test, with or without the define
"DEFAULT_THUMB_ADR_SETS_INTERWORKING",
but my test are always fails (no boot of my kernel).
The only thing I seen it's working are to made a modification on the
kernel following the tread: https://patchwork.kernel.org/patch/10072631/.
For binutils, actually I have some doubt I have made a basic test to
comment the part of code on do_adr and do_adrl for thumb part and I always
generate the same code which doesn't boot.
Thanks
Regards
Christophe
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <ec2b0134-6c4a-53ff-4ae2-69c3f0646ded@redhat.com>
@ 2018-06-05 14:11 ` Christophe PRIOUZEAU
[not found] ` <1d8f302b-5ece-9921-b930-8c4bca61743e@redhat.com>
[not found] ` <1d8f302b-5ece-9921-b930-8c4bca61743e@redhat. com>
0 siblings, 2 replies; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-05 14:11 UTC (permalink / raw)
To: buildroot
Hi Nick,
On 06/05/2018 01:37 PM, Nick Clifton wrote:
> Hi Christophe, Hi Romain,
>
>> I have made several test, with or without the define
>> "DEFAULT_THUMB_ADR_SETS_INTERWORKING",
>> but my test are always fails (no boot of my kernel).
> OK - now I am confused. If changing the behaviour of the ADR and ADRL
> pseudo-ops is not working, then what is causing the boot failure ?
>
> Hmm, or is it that my patch is not working (at all) and not changing
> anything.
>
> Christophe - are you able to supply an assembler source file that
> I can try assembling to see what changes, if anything, when I use
> the new options ?
>
> Cheers
> Nick
>
>
I'm not able to provide a simplest code which generate a bad assembler.
I have only the source code of kernel 4.11 use on my configuration of
buildroot.
On code generated we see the issue on entry-common.o
(arch/arm/kernel/entry-common.o):
code ok: f2af 1e3b ??? subw??? lr, pc, #315??? ; 0x13b
code KO: f2af 1e3a ??? subw??? lr, pc, #314??? ; 0x13a
(see assembler code obtained by objdump)
Info:
AFLAGS=-Wp,-MD,arch/arm/kernel/.entry-common.o.d? -nostdinc -isystem
/mnt/internal_storage/stm32f7/buildroot_to_test_02/output/host/lib/gcc/arm-buildroot-uclinux-uclibcgnueabi/6.4.0/include
-I./arch/arm/include -I./arch/arm/include/generated/uapi
-I./arch/arm/include/generated? -I./include -I./arch/arm/include/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -D__ASSEMBLY__
-fno-PIE -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
-funwind-tables -mthumb -Wa,-mimplicit-it=always
-Wa,-mno-warn-deprecated -Wa,-mthumb -D__LINUX_ARM_ARCH__=7
-march=armv7-m -Wa,-march=armv7-m -include asm/unified.h -msoft-float
-DCC_HAVE_ASM_GOTO -Wa,-gdwarf-2
/mnt/internal_storage/stm32f7/buildroot_to_test_02/output/host/bin/arm-buildroot-uclinux-uclibcgnueabi-gcc
-Wp,-MD,arch/arm/kernel/.entry-common.o.d? -nostdinc -isystem
/mnt/internal_storage/stm32f7/buildroot_to_test_02/output/host/lib/gcc/arm-buildroot-uclinux-uclibcgnueabi/6.4.0/include
-I./arch/arm/include -I./arch/arm/include/generated/uapi
-I./arch/arm/include/generated? -I./include -I./arch/arm/include/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -D__ASSEMBLY__
-fno-PIE -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
-funwind-tables -mthumb -Wa,-mimplicit-it=always
-Wa,-mno-warn-deprecated -Wa,-mthumb -D__LINUX_ARM_ARCH__=7
-march=armv7-m -Wa,-march=armv7-m -include asm/unified.h -msoft-float
-DCC_HAVE_ASM_GOTO -Wa,-gdwarf-2?? -c -o arch/arm/kernel/entry-common.o
arch/arm/kernel/entry-common.S
PS: More I made test and more I don't understand what are generating the
issue.
With the test provided on mail thread:
https://patchwork.kernel.org/patch/10072631/ , I obtain the same code
with the two version of binutils (2.28.1 and 2.30).
I Hope this kind of information can help you.
Thanks for yours time.
Regards
Christophe
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: entry-common_disassembled_kernel_4.11_functionnal.objdump
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180605/79cc7035/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: entry-common_disassembled_kernel_4.11_ko.objdump
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180605/79cc7035/attachment-0001.ksh>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <1d8f302b-5ece-9921-b930-8c4bca61743e@redhat.com>
@ 2018-06-11 14:47 ` Christophe PRIOUZEAU
0 siblings, 0 replies; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-11 14:47 UTC (permalink / raw)
To: buildroot
Hi Nick,
On 06/11/2018 04:03 PM, Nick Clifton wrote:
> Hi Christophe,
>
>> On code generated we see the issue on entry-common.o
>> (arch/arm/kernel/entry-common.o):
>> code ok: f2af 1e3b ??? subw??? lr, pc, #315??? ; 0x13b
>> code KO: f2af 1e3a ??? subw??? lr, pc, #314??? ; 0x13a
>> (see assembler code obtained by objdump)
> OK - so this translates to the use of the "badr" macro defined
> in include/asm/assembler.h:
>
> .macro badr\c, rd, sym
> #ifdef CONFIG_THUMB2_KERNEL
> adr\c \rd, \sym + 1
> #else
> adr\c \rd, \sym
> #endif
> .endm
>
>
> What is the CONFIG_THUMB2_KERNEL flag ?
Defiinition of CONFIG_THUMB2_KERNEL
config THUMB2_KERNEL "Compile the kernel in Thumb-2 mode"
??? help
??? ? By enabling this option, the kernel will be compiled in
??? ? Thumb-2 mode. A compiler/assembler that understand the unified
??? ? ARM-Thumb syntax is needed.
>
> I am wondering why it alters the behaviour of the badr macro...
>
>
>> -fno-PIE -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
> Question - is the -mno-thumb-interwork flag always used ?
The compilation option "-mno-thumb-interwork" are used only
if "CONFIG_AEABI" are put in place for arm platform therefore yes for
arm cortex-M
is used on all ARM of kernel configuration.
>
> It seems to me that this flag might provide a much simpler option
> to fix the assembler. Ie: if -mthumb-interwork is enabled then
> the ADR pseudo-instruction should include the interworking bit (for
> thumb function symbols), whereas if -mno-thumb-interwork is in
> effect, then it should not.
>
> Cheers
> Nick
Info for CONFIG_AEABI: Use the ARM EABI to compile the kernel.
This option allows for the kernel to be compiled using the latest
ARM ABI (aka EABI).? This is only useful if you are using a user
space environment that is also compiled with EABI.
Since there are major incompatibilities between the legacy ABI and
EABI, especially with regard to structure member alignment, this
option also changes the kernel syscall calling convention to
disambiguate both ABIs and allow for backward compatibility support
Thanks for the analysis
--
Best regards / Cordialement,
Christophe Priouzeau | Tel: +33 244027320
STMicroelectronics
ST online: www.st.com<http://www.st.com/>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <be2db8d4-7c12-2706-5084-322aa659c3bc@redhat.com>
@ 2018-06-18 15:04 ` Christophe PRIOUZEAU
2018-06-18 18:29 ` Romain Naour
0 siblings, 1 reply; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-18 15:04 UTC (permalink / raw)
To: buildroot
Hi Nick,
On 06/18/2018 04:03 PM, Nick Clifton wrote:
> Hi Guys,
>
> Has there been any further progress on this issue ?
>
> Does my suggestion of making the assembler's interpretation of
> the ADR and ADRL pseudo-ops depend upon the -mthumb-interwork
> switch seem like a good idea ?
>
> Cheers
> Nick
>
>
I think it's a good trigger but I'm not an expert on this domain.
Regards
Christophe
--
Best regards / Cordialement,
Christophe Priouzeau | Tel: +33 244027320
STMicroelectronics
ST online: www.st.com<http://www.st.com/>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
2018-06-18 15:04 ` Christophe PRIOUZEAU
@ 2018-06-18 18:29 ` Romain Naour
[not found] ` <062a421f-a669-fc1c-91e0-88cf73794414@redhat.com>
0 siblings, 1 reply; 34+ messages in thread
From: Romain Naour @ 2018-06-18 18:29 UTC (permalink / raw)
To: buildroot
Hi Nick,
Le 18/06/2018 ? 17:04, Christophe PRIOUZEAU a ?crit?:
> Hi Nick,
> On 06/18/2018 04:03 PM, Nick Clifton wrote:
>> Hi Guys,
>>
>> Has there been any further progress on this issue ?
>>
>> Does my suggestion of making the assembler's interpretation of
>> the ADR and ADRL pseudo-ops depend upon the -mthumb-interwork
>> switch seem like a good idea ?
>>
>> Cheers
>> Nick
>>
>>
> I think it's a good trigger but I'm not an expert on this domain.
Same here...
I'm not sure how many project enable -mthumb-interwork option.
Best regards,
Romain
> Regards
> Christophe
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* [Buildroot] Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils
[not found] ` <062a421f-a669-fc1c-91e0-88cf73794414@redhat.com>
@ 2018-06-19 12:27 ` Christophe PRIOUZEAU
0 siblings, 0 replies; 34+ messages in thread
From: Christophe PRIOUZEAU @ 2018-06-19 12:27 UTC (permalink / raw)
To: buildroot
HI Nick,
On 06/19/2018 02:01 PM, Nick Clifton wrote:
> Hi Romain,
>
>>>> Does my suggestion of making the assembler's interpretation of
>>>> the ADR and ADRL pseudo-ops depend upon the -mthumb-interwork
>>>> switch seem like a good idea ?
>>> I think it's a good trigger but I'm not an expert on this domain.
>> Same here...
>> I'm not sure how many project enable -mthumb-interwork option.
> Well actually that is the point. By making the ADR/ADRL pseudo-ops
> only set the bottom bit if the -mthumb-interwork option is used, we
> will effectively be restoring the old behaviour of the assembler to
> any project that does not use it. So the ARM kernel in particular
> will get the old behaviour back, which is what I think is wanted.
>
> So - any objections to the change ? Anyone ?
>
> Cheers
> Nick
>
>
>
>
I'm ok with this approach, and I'm available for possible patches to test.
Regards
Christophe
--
Best regards / Cordialement,
Christophe Priouzeau | Tel: +33 244027320
STMicroelectronics
ST online: www.st.com<http://www.st.com/>
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2018-06-19 12:27 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-21 17:27 [PATCH] arm: ensure symbol is a thumb symbol in new binutils Jason A. Donenfeld
2017-11-21 17:27 ` Jason A. Donenfeld
2017-11-21 17:38 ` Russell King - ARM Linux
2017-11-21 17:38 ` Russell King - ARM Linux
2017-11-21 17:46 ` Jason A. Donenfeld
2017-11-21 17:46 ` Jason A. Donenfeld
2017-11-21 17:49 ` Russell King - ARM Linux
2017-11-21 17:49 ` Russell King - ARM Linux
2017-11-22 23:34 ` Jason A. Donenfeld
2017-11-22 23:34 ` Jason A. Donenfeld
2017-11-23 10:35 ` Russell King - ARM Linux
2017-11-23 10:35 ` Russell King - ARM Linux
2017-11-23 10:47 ` Fwd: " Jason A. Donenfeld
2017-11-23 10:47 ` Jason A. Donenfeld
2017-11-23 11:48 ` [PATCH] arm: detect buggy binutils when in thumb2 mode Jason A. Donenfeld
2017-11-23 11:48 ` Jason A. Donenfeld
2017-11-23 11:50 ` [PATCH v2] " Jason A. Donenfeld
2017-11-23 11:50 ` Jason A. Donenfeld
2017-11-23 12:01 ` Martin Storsjö
2017-11-23 12:01 ` Martin Storsjö
2017-11-23 14:02 ` Fwd: [PATCH] arm: ensure symbol is a thumb symbol in new binutils Russell King - ARM Linux
2017-11-23 14:02 ` Russell King - ARM Linux
2017-11-23 14:26 ` Ard Biesheuvel
2017-11-23 14:26 ` Ard Biesheuvel
2017-11-23 14:26 ` Ard Biesheuvel
[not found] ` <765227b5-981d-0cea-c831-73cfe2f58721@redhat.com>
[not found] ` <aaf57bb5-13e6-852c-0f67-f72aedef0e79@gmail.com>
[not found] ` <254af731-459b-1f1d-2d93-27c5a91e7bfb@redhat.com>
2018-05-31 21:16 ` [Buildroot] " Romain Naour
2018-06-01 8:28 ` Christophe PRIOUZEAU
[not found] ` <2a8151c1-644e-a6b0-9a21-2c570ac7000b@redhat.com>
2018-06-05 8:52 ` Christophe PRIOUZEAU
[not found] ` <ec2b0134-6c4a-53ff-4ae2-69c3f0646ded@redhat.com>
2018-06-05 14:11 ` Christophe PRIOUZEAU
[not found] ` <1d8f302b-5ece-9921-b930-8c4bca61743e@redhat.com>
2018-06-11 14:47 ` Christophe PRIOUZEAU
[not found] ` <1d8f302b-5ece-9921-b930-8c4bca61743e@redhat. com>
[not found] ` <CAJA7tRbsNa7oTS-1sLs0WpA74RZr0R-v=sCyQxbDam5Gb7fYHA@mail.gmail.com>
[not found] ` <be2db8d4-7c12-2706-5084-322aa659c3bc@redhat.com>
2018-06-18 15:04 ` Christophe PRIOUZEAU
2018-06-18 18:29 ` Romain Naour
[not found] ` <062a421f-a669-fc1c-91e0-88cf73794414@redhat.com>
2018-06-19 12:27 ` Christophe PRIOUZEAU
2018-01-16 8:43 ` Chen-Yu Tsai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.