[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Will Deacon]

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

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Russell King - ARM Linux]

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?

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Will Deacon]

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 | \

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Russell King - ARM Linux]

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.

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Will Deacon]

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

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Russell King - ARM Linux]

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).

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Will Deacon]

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

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Arnaud Patard (Rtp)]

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

[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

[Russell King - ARM Linux]

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.