* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils @ 2012-08-02 12:23 Will Deacon 2012-08-02 13:04 ` Russell King - ARM Linux 0 siblings, 1 reply; 9+ messages in thread From: Will Deacon @ 2012-08-02 12:23 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Will Deacon <will.deacon@arm.com> --- arch/arm/boot/compressed/Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index bb26756..0f7f3f4 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -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 | \ -- 1.7.4.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 12:23 [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils Will Deacon @ 2012-08-02 13:04 ` Russell King - ARM Linux 2012-08-02 15:01 ` Will Deacon 0 siblings, 1 reply; 9+ messages in thread From: Russell King - ARM Linux @ 2012-08-02 13:04 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 01:23:26PM +0100, Will Deacon wrote: > 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. 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 13:04 ` Russell King - ARM Linux @ 2012-08-02 15:01 ` Will Deacon 2012-08-02 15:30 ` Russell King - ARM Linux 0 siblings, 1 reply; 9+ messages in thread From: Will Deacon @ 2012-08-02 15:01 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, On Thu, Aug 02, 2012 at 02:04:11PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 02, 2012 at 01:23:26PM +0100, Will Deacon wrote: > > 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. > > 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. > 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<--- diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index bb26756..3774f0d 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -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 | \ ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 15:01 ` Will Deacon @ 2012-08-02 15:30 ` Russell King - ARM Linux 2012-08-02 15:51 ` Will Deacon 0 siblings, 1 reply; 9+ messages in thread From: Russell King - ARM Linux @ 2012-08-02 15:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 04:01:23PM +0100, Will Deacon wrote: > Hi Russell, > > On Thu, Aug 02, 2012 at 02:04:11PM +0100, Russell King - ARM Linux wrote: > > On Thu, Aug 02, 2012 at 01:23:26PM +0100, Will Deacon wrote: > > > 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. > > > > 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. > > > 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)? It might just be easier to specify something like -march=armv4 or something like that, and then use .arch armv6 where required. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 15:30 ` Russell King - ARM Linux @ 2012-08-02 15:51 ` Will Deacon 2012-08-02 18:18 ` Russell King - ARM Linux 0 siblings, 1 reply; 9+ messages in thread From: Will Deacon @ 2012-08-02 15:51 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 04:30:30PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 02, 2012 at 04:01:23PM +0100, Will Deacon wrote: > > On Thu, Aug 02, 2012 at 02:04:11PM +0100, Russell King - ARM Linux wrote: > > > 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)? > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 15:51 ` Will Deacon @ 2012-08-02 18:18 ` Russell King - ARM Linux 2012-08-02 18:50 ` Will Deacon 0 siblings, 1 reply; 9+ messages in thread From: Russell King - ARM Linux @ 2012-08-02 18:18 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 04:51:41PM +0100, Will Deacon wrote: > On Thu, Aug 02, 2012 at 04:30:30PM +0100, Russell King - ARM Linux wrote: > > On Thu, Aug 02, 2012 at 04:01:23PM +0100, Will Deacon wrote: > > > On Thu, Aug 02, 2012 at 02:04:11PM +0100, Russell King - ARM Linux wrote: > > > > 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)? > > > > 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 18:18 ` Russell King - ARM Linux @ 2012-08-02 18:50 ` Will Deacon 2012-08-02 19:09 ` Arnaud Patard (Rtp) 2012-08-02 19:44 ` Russell King - ARM Linux 0 siblings, 2 replies; 9+ messages in thread From: Will Deacon @ 2012-08-02 18:50 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 07:18:10PM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 02, 2012 at 04:51:41PM +0100, Will Deacon wrote: > > On Thu, Aug 02, 2012 at 04:30:30PM +0100, Russell King - ARM Linux wrote: > > > 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. 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. > 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. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 18:50 ` Will Deacon @ 2012-08-02 19:09 ` Arnaud Patard (Rtp) 2012-08-02 19:44 ` Russell King - ARM Linux 1 sibling, 0 replies; 9+ messages in thread From: Arnaud Patard (Rtp) @ 2012-08-02 19:09 UTC (permalink / raw) To: linux-arm-kernel Will Deacon <will.deacon@arm.com> writes: > On Thu, Aug 02, 2012 at 07:18:10PM +0100, Russell King - ARM Linux wrote: >> On Thu, Aug 02, 2012 at 04:51:41PM +0100, Will Deacon wrote: >> > On Thu, Aug 02, 2012 at 04:30:30PM +0100, Russell King - ARM Linux wrote: >> > > 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. > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils 2012-08-02 18:50 ` Will Deacon 2012-08-02 19:09 ` Arnaud Patard (Rtp) @ 2012-08-02 19:44 ` Russell King - ARM Linux 1 sibling, 0 replies; 9+ messages in thread From: Russell King - ARM Linux @ 2012-08-02 19:44 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 02, 2012 at 07:50:33PM +0100, Will Deacon wrote: > 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. > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-08-02 19:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-02 12:23 [PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils Will Deacon 2012-08-02 13:04 ` Russell King - ARM Linux 2012-08-02 15:01 ` Will Deacon 2012-08-02 15:30 ` Russell King - ARM Linux 2012-08-02 15:51 ` Will Deacon 2012-08-02 18:18 ` Russell King - ARM Linux 2012-08-02 18:50 ` Will Deacon 2012-08-02 19:09 ` Arnaud Patard (Rtp) 2012-08-02 19:44 ` Russell King - ARM Linux
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).