Re: new binutils needed for arm in 3.12-rc1

From: Rob Landley
Date: Wed Sep 25 2013 - 11:23:15 EST

On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
On Tue, 24 Sep 2013, Rob Landley wrote:

> On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
> > 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.

If you are convinced you have no choice but to stick to old binutils,

Oh no, long-term other choices include and but they're not ready yet and I don't have time to work on them right now. (I had high hopes for gold, until the guy signed it over to the FSF and it vanished into the tiergruben. Oh well.)

I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel more complex.

Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything.

Whereas if I add an old binutils config option, other people might help regression test it (if not actually fix it), and the other toolchain projects have less of a moving target to catch up to.

This is more in line with being future proof rather than stuck into the past.

No, it's exactly the opposite of that. Future proof is getting off a toolchain whose license is a moving target.

GPLv2: "shut up and show me the code"
GPLv3: "I am altering the bargain, pray I don't alter it any further."
GPLv4: ???

It could be as simple as making gas accept an extra argument for
instructions like dsb and just ignoring it.

So you prefer I come up with the reversion patches locally and _not_ send them upstream?

*shrug* That's what I've been doing for sh4 for around 4 years now. (And their breakage still reverts cleanly even.) It's also what I did when the arm versatile interrupts changed randomly 3 times in ways that weren't backwards compatible with existing qemu versions. And I maintained perl removal patches for 5 years before they finally went upstream.

But I do at least post said patches publicly, and other people use 'em when I do...

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