Re: new binutils needed for arm in 3.12-rc1

From: Rob Landley
Date: Tue Sep 24 2013 - 21:13:37 EST

On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote:
> What value is there in requiring the new toolchain? From what I could
> see of the commits it was micro-optimizations around memory barriers.
> *shrug* I can revert the patch locally, or patch the extra instruction
> into my toolchain. But I do object to changing the documentation
> globally for every architecture because one architecture did something
> they apparently never thought through (or they'd have commented in the
> commit that it requires a big toolchain version jump; pretty sure they
> didn't actually notice).

Some of us are notoriously slow at updating our toolchains.

Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM or some such provides a complete solution.

Now, if you feel strongly about this, we _could_ introduce a
CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
fragile. Not everyone will remember to get that right, because they'll
be using the later binutils. Also, we already have an excessive number
of potential breakage-inducing options and we certainly don't need

I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream.

My use case is running all these targets under qemu, so it's not exactly performance-critical. :)

Use IS_ENABLED() I hear you say. That won't get the one dsb instruction
in some SoC code which was missed which will break the build on older

My regression test is my project, where I:

1) build cross compilers for ~15 different architecture variants (maybe half unique, the rest variants of the others).

2) Use them to build the smallest native development environment capable of reproducing itself from soruce code.

3) Boot it under qemu.

4) Build linux from scratch under the result.

I've sometimes had it the whole mess automated from a cron job, but the server I had it on blew out its hard drive controller and I haven't bothered to set it up again...

Next couple days are crazy but I'll try to get you a patch this weekend.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at