Re: new binutils needed for arm in 3.12-rc1

[Rob Landley]

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

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

My regression test is my http://landley.net/aboriginal/about.html  
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.

Thanks,

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/