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: <1380057828.1974.73@driftwood>
Date:	Tue, 24 Sep 2013 16:23:48 -0500
From:	Rob Landley <rob@...dley.net>
To:	Måns Rullgård <mans@...sr.com>
Cc:	Pavel Machek <pavel@....cz>, Will Deacon <will.deacon@....com>,
	Trivial patch monkey <trivial@...nel.org>,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Catalin Marinas <Catalin.Marinas@....com>
Subject: Re: new binutils needed for arm in 3.12-rc1

On 09/24/2013 07:11:38 AM, Måns Rullgård wrote:
> Rob Landley <rob@...dley.net> writes:
> 
> > On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> >> During 3.12-rc, Will Deacon introduced code into arch/arm that
> >> requires binutils 2.22.
> >
> > Um, my toolchain is using the last gplv2 snapshot of binutils out of
> > git, which is just past 2.17 and can build armv7 (but not armv8).
> >
> > Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some
> > thought to have gone into that? Possibly a mention of it?
> 
> I seriously doubt that 2.12 still works at all (I doubt it can even be
> built on a modern system).  In my experience, binutils older than 2.19
> or so rarely works properly for ARM.

I've been building every kernel release with 2.17 for several years, on  
a bunch of different architectures. Toolchain releases after that are  
GPLv3* and I can't distribute those binaries, so I can't ship prebuilt  
binary toolchains.

(Lots of other people produce cross compilers, but nobody else seems to  
produce prebuilt statically linked _native_ compilers. It would be nice  
if they did.)

> What value is there in maintaining compatibility with a truly ancient
> binutils version anyway?

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

Rob

* The Free Software Foundation got so pissed that MacOS X and BSD and  
such were sticking with the last GPLv2 release of binutils that they  
deleted the binutils tarball off their website and replaced it with one  
including GPLv3 source code. Check the FTP site if you don't believe  
me. Some of us have it snapshotted though. In my case, I actually  
fished the last GPLv2 version out of source control, right before the  
license change was committed, because I wanted armv7 support.--
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/