Re: new binutils needed for arm in 3.12-rc1

Rob Landley
2013-09-26T22:48:34Z

On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote:
> On Wed, 25 Sep 2013, Rob Landley wrote:
>
> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> > > 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.
>
> Gnuism?
>
> Let me quote the ARM ARchitecture Reference Manual, version 7
> revision C,
> section A8.8.44 (sorry for the whitespace dammage):

Globally changing the binutils requirement for all architectures, as
the doc patch at the start of this thread proposed doing, would mean
gnuisms in common code (ext2 and such) wouldn't get caught, giving llvm
and pcc and such a moving target when trying to build the kernel with
non-gnu toolchains. That's what I meant by gnuisms breeding.

> So what's the link with the above and your issue with GPLv3, besides
> the
> fact that the last binutils version to have been released under the
> GPLv2 is defficient?

I apparently wasn't clear. The new instructions aren't gnuisms. The
lack of widespread regression testing for armv5l and such would allow
introduction of nonportable constructs in a larger context.

(The fact that armv7 could apparently build fine for ~7 years with
binutils 2.18 through 2.21, and now it's suddenly can't Because Reasons
is kinda silly, but not really a big deal. That, I can patch my
toolchain.)

> > > 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?
>
> Sort of. And I'm suggesting you patch your binutils rather than the
> kernel.

I had this misidentified as a global arm problem and not specific to
arm7l. If armv5l still still builds with the old toolchains, it's not a
big deal.

> Given you're not upgrading your binutils anymore that means
> you'll have to apply that patch only once instead of having to apply
> it
> to every kernel upgrade.

Indeed. Patching my own toolchain isn't really a problem. My objection
was to the Documentation patch telling the world at large that for all
targets, older binutils aren't supported even on x86. That was worth
pushing back against.

I don't indend to use old gcc/binutils versions forever, I just want to
be able to use them until I can replace them with llvm or similar.

Rob