ARM: makefile: work around toolchain bug in recent versions of binutils
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Recent upstream versions of binutils fail to assembler compressed/head.S when passed the -march=all option:
http://lists.gnu.org/archive/html/bug-binutils/2011-04/msg00162.html
The recommended workaround from the tools folks is not to pass the option, and instead let the assembler deduce the CPU type based on the features used by the code.
--- arch/arm/boot/compressed/Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
arch/arm/boot/compressed/Makefile +0 -1
@@ -126,7 +126,6 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS)) endif ccflags-y := -fpic -fno-builtin -I$(obj) -asflags-y := -Wa,-march=all # Supply kernel BSS size to the decompressor via a linker symbol. KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
Signature · 1 line
1.7.4.1
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 8 lines · Will Deacon
Recent upstream versions of binutils fail to assembler
compressed/head.Swhen passed the -march=all option:http://lists.gnu.org/archive/html/bug-binutils/2011-04/msg00162.html
The recommended workaround from the tools folks is not to pass the option, and instead let the assembler deduce the CPU type based on the features used by the code.
That doesn't work for all binutils - binutils historically has had to be told explicitly what architecture its building for and won't "deduce" it from the code.
Maybe this needs to be a build-time test whether the assembler accepts it?
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Hi Russell,
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Will Deacon
Recent upstream versions of binutils fail to assembler
compressed/head.Swhen passed the -march=all option:http://lists.gnu.org/archive/html/bug-binutils/2011-04/msg00162.html
Quoted 7 lines
Quoted 3 lines
The recommended workaround from the tools folks is not to pass the option, and instead let the assembler deduce the CPU type based on the features used by the code.
That doesn't work for all binutils - binutils historically has had to be told explicitly what architecture its building for and won't "deduce" it from the code.
Damn. I thought there would be a reason why we passed the option in the first place.
Quoted 1 line
Maybe this needs to be a build-time test whether the assembler accepts it?
That could be tricky since gas still accepts the option, but fails later with:
arch/arm/boot/compressed/head.S: Assembler messages:arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2'
How about grabbing the march from KBUILD_AFLAGS instead (see below)?
Will
---8<---
arch/arm/boot/compressed/Makefile +1 -1
@@ -126,7 +126,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS)) endif ccflags-y := -fpic -fno-builtin -I$(obj) -asflags-y := -Wa,-march=all +asflags-y := -Wa,$(lastword $(filter -march=%,$(KBUILD_AFLAGS))) # Supply kernel BSS size to the decompressor via a linker symbol. KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 25 lines · Will Deacon
Hi Russell,
Quoted 6 lines · Russell King - ARM Linux
Quoted 5 lines · Will Deacon
Recent upstream versions of binutils fail to assembler
compressed/head.Swhen passed the -march=all option:http://lists.gnu.org/archive/html/bug-binutils/2011-04/msg00162.html
Quoted 7 lines
Quoted 3 lines
The recommended workaround from the tools folks is not to pass the option, and instead let the assembler deduce the CPU type based on the features used by the code.
That doesn't work for all binutils - binutils historically has had to be told explicitly what architecture its building for and won't "deduce" it from the code.
Damn. I thought there would be a reason why we passed the option in the first place.
Quoted 1 line
Maybe this needs to be a build-time test whether the assembler accepts it?
That could be tricky since gas still accepts the option, but fails later with:
Quoted 6 lines
arch/arm/boot/compressed/head.S: Assembler messages:arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register --mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register --mrs r2,cpsr'arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2'How about grabbing the march from
KBUILD_AFLAGSinstead (see below)?
It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required.
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 12 lines · Russell King - ARM Linux
Quoted 11 lines · Will Deacon
Quoted 1 line · Russell King - ARM Linux
Maybe this needs to be a build-time test whether the assembler accepts it?
That could be tricky since gas still accepts the option, but fails later with:
arch/arm/boot/compressed/head.S: Assembler messages:arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register --mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register --mrs r2,cpsr'arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2'
Quoted 4 lines
Quoted 1 line
How about grabbing the march from
KBUILD_AFLAGSinstead (see below)?It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required.
We could do that, but I worry that it will become very messy if/when people start adding things like virtualisation instructions (hvc and co) to the entry code. Using the same march flag for kernel and decompressor also keeps everything consistent.
Will
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 15 lines · Will Deacon
Quoted 14 lines · Russell King - ARM Linux
Quoted 12 lines · Will Deacon
Quoted 1 line · Russell King - ARM Linux
Maybe this needs to be a build-time test whether the assembler accepts it?
That could be tricky since gas still accepts the option, but fails later with:
arch/arm/boot/compressed/head.S: Assembler messages:arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register --mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register --mrs r2,cpsr'arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2'How about grabbing the march from
KBUILD_AFLAGSinstead (see below)?
Quoted 7 lines
Quoted 2 lines
It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required.
We could do that, but I worry that it will become very messy if/when people start adding things like virtualisation instructions (hvc and co) to the entry code. Using the same march flag for kernel and decompressor also keeps everything consistent.
But you're missing a fundamental point: the decompressor is not designed to be built like that, it is designed to be built in such a way that it works unmodified on any CPU type we have to date, whether you're building a kernel for ARMv4 or ARMv7.
So, the code sequences which are architecture specific are only executed after we've checked the ID registers to determine what we should be doing for a particular CPU.
Hence, even if you're building for ARMv4, the decompressor will _still_ contain all the support code for ARMv7 - and the assembler better accept those instructions too.
The alternative is we scatter various places with lots of yucky ifdefs, and it won't be pretty because quite a number of CPUs share the same code (which leads to long #if defined(CPU_A) || defined(CPU_B) etc).
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 10 lines · Russell King - ARM Linux
Quoted 8 lines · Will Deacon
Quoted 2 lines · Russell King - ARM Linux
It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required.
We could do that, but I worry that it will become very messy if/when people start adding things like virtualisation instructions (hvc and co) to the entry code. Using the same march flag for kernel and decompressor also keeps everything consistent.
Quoted 8 lines
But you're missing a fundamental point: the decompressor is not designed to be built like that, it is designed to be built in such a way that it works unmodified on any CPU type we have to date, whether you're building a kernel for ARMv4 or ARMv7.
So, the code sequences which are architecture specific are only executed after we've checked the ID registers to determine what we should be doing for a particular CPU.
That's fine, *if* we can persuade the tools to build the thing for us. With march=all, we got what we wanted but now that doesn't seem to work anymore.
Quoted 3 lines
Hence, even if you're building for ARMv4, the decompressor will _still_ contain all the support code for ARMv7 - and the assembler better accept those instructions too.
With recent tools, it looks like that's really hard to do... simply passing the lowest common denominator of march=armv4 will cause the assembler to barf on all the non-v4 code, which includes Thumb ("Error: selected processor does not support THUMB opcodes"). It sounds like we want to pass the march option corresponding to the highest architecture version supported by the kernel being compiled (assuming we don't use anything that gets deprecated by a later version of the architecture(!)).
Yuck.
Quoted 3 lines
The alternative is we scatter various places with lots of yucky ifdefs, and it won't be pretty because quite a number of CPUs share the same code (which leads to long #if
defined(CPU_A)||defined(CPU_B)etc).
That'll work, but let's keep it as a last resort. This is still a toolchain issue we're dealing with here.
Will
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
Quoted 16 lines · Will Deacon
Quoted 15 lines · Russell King - ARM Linux
Quoted 8 lines · Will Deacon
Quoted 2 lines · Russell King - ARM Linux
It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required.
We could do that, but I worry that it will become very messy if/when people start adding things like virtualisation instructions (hvc and co) to the entry code. Using the same march flag for kernel and decompressor also keeps everything consistent.
But you're missing a fundamental point: the decompressor is not designed to be built like that, it is designed to be built in such a way that it works unmodified on any CPU type we have to date, whether you're building a kernel for ARMv4 or ARMv7.
Quoted 7 lines
Quoted 3 lines
So, the code sequences which are architecture specific are only executed after we've checked the ID registers to determine what we should be doing for a particular CPU.
That's fine, *if* we can persuade the tools to build the thing for us. With march=all, we got what we wanted but now that doesn't seem to work anymore.
and we already had to fix -march=all in the past :
http://sourceware.org/bugzilla/show_bug.cgi?id=12698
So maybe would be easier to try to fix it instead of trying to workaround it ?
Arnaud
PATCH 1/1 ARM: makefile: work around toolchain bug in recent versions of binutils
In reply to Will DeaconQuoted 7 lines · Will Deacon
With recent tools, it looks like that's really hard to do... simply passing the lowest common denominator of march=armv4 will cause the assembler to barf on all the non-v4 code, which includes Thumb ("Error: selected processor does not support THUMB opcodes"). It sounds like we want to pass the march option corresponding to the highest architecture version supported by the kernel being compiled (assuming we don't use anything that gets deprecated by a later version of the architecture(!)).
This is where having an option of "create opcodes exactly from the assembly I specify in this file, I know what I'm doing, and I don't care that some instructions aren't present on various CPUs" becomes a requirement than a desire.
Quoted 6 lines
Quoted 3 lines
The alternative is we scatter various places with lots of yucky ifdefs, and it won't be pretty because quite a number of CPUs share the same code (which leads to long #if
defined(CPU_A)||defined(CPU_B)etc).That'll work, but let's keep it as a last resort. This is still a toolchain issue we're dealing with here.
Another possibility is to use .word for the instructions as refuses to use for us, which is also yuck.
The more the binutils folk decide that they should be gods and rule what code we can write, the more work-arounds we will have to find. Maybe that even gets to the point of having to write our own assembler... It wouldn't be the first time that something like that has been done because a mainstream project imposed too many silly conditions on their users.