| Message ID | 20120802150123.GE9838@mudshark.cambridge.arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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).
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
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
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.
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 | \