| Message ID | 20171121173857.GJ31757@n2100.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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...
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
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.
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