linux-kernel - Re: new binutils needed for arm in 3.12-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1380235709.1974.93@driftwood>
Date:	Thu, 26 Sep 2013 17:48:29 -0500
From:	Rob Landley <rob@...dley.net>
To:	Nicolas Pitre <nico@...xnic.net>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Måns Rullgård <mans@...sr.com>,
	Andrew Morton <akpm@...l.org>,
	Trivial patch monkey <trivial@...nel.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: new binutils needed for arm in 3.12-rc1

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/