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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 24 Sep 2013 22:48:00 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Rob Landley <rob@...dley.net>
Cc:	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 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.  I'm still
using gcc 4.5.4 here, and people regard that as bordering on "too old"
because of the amount of warnings it spits out.  Binutils?  I upgraded
to 2.22 when I needed to fix a problem I was having with the previous
binutils I was using (I think that was 2.18).

I generally don't touch my toolchain unless there's a _reason_ I need
to, and as I've already updated to 2.22, it's a normally a pretty safe
bet that everyone else is already using 2.22 or later.  One reason for
this is that I don't want to be messing around trying to work out
whether a bug I'm seeing is because of a toolchain problem or something
in the kernel.

I realised at the time that I'm going to got shouted at if I accepted
the patches by a minority who wanted to keep their old toolchains, but
I also realise that if I don't accept the patches, I'll get shouted at
by another group.  It's the classic damned if I do and damned if I
don't.  So I've chosen the lesser of the two weavels.

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.

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