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: <alpine.DEB.2.00.1605161452100.6794@tp.orcam.me.uk>
Date:	Fri, 20 May 2016 14:21:34 +0100
From:	"Maciej W. Rozycki" <macro@...tec.com>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	stable <stable@...r.kernel.org>,
	Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
	Ben Hutchings <ben@...adent.org.uk>,
	Li Zefan <lizefan@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Building older mips kernels with different versions of binutils;
 possible patch for 3.2 and 3.4

Hi Guenter,

> building mips images with a consistent infrastructure is becoming more and
> more difficult.

 As the current MIPS binutils maintainer I am sorry to hear about this, 
and apologise for the state of affairs.  Of course I can't help with any 
sins of the past, but at least I can help straightening out the current 
situation and making sure that the most recent binutils work as expected.

> Current state is as follows.
> 
> Binutils/	2.22	2.24	2.25
> Kernel
> 3.2		X	-	-
> 3.4		X	-	-
> 3.10		X	X	-
> 3.14		X	X	-
> 3.16		X	X	-
> 3.18		X	X	(X) [1]
> 4.1		X	X	(X)
> 4.4		X	X	(X)
> 4.5		X	X	(X)
> 4.6		X	X	(X)
> next		-	X	(X)
> 
> [1] (at least) allnoconfig fails to build with binutils 2.25 (2.25.1, more
> specifically).
> 
> I used the following toolchains for the above tests:
> - Poky 1.3 (binutils 2.22)
> - Poky 2.0 (binutils 2.25.1)
> - gcc-4.6.3-nolibc from kernel.org (binutils 2.22)
> - gcc-4.9.0-nolibc from kernel.org (binutils 2.24)
> 
> For 3.4 and 3.2 kernels to build with binutils v2.24, it would be necessary to
> apply patch c02263063362 ("MIPS: Refactor 'clear_page' and 'copy_page'
> functions").

 Mind that this change is really only needed to build microMIPS kernels, 
only required for pure microMIPS hardware, i.e. processors which do not 
support regular (aka AD 1985 classic) MIPS execution at all -- have you 
been building such configurations?  For mixed-mode processors a regular 
MIPS kernel will do as it'll handle microMIPS userland just fine.

 Or is there a hidden catch in this change beyond what's been stated in 
the commit description?

> It applies cleanly to 3.4, but has a Makefile conflict in 3.2. It might
> make sense to apply this patch to both releases. Would this be possible ?
> This way, we would have at least one toolchain which can build all 3.2+
> kernels.

 If you send me messages from build errors you think may be caused by an 
incompatibility between the most recent binutils and kernel code, along 
with a kernel GIT commit ID, then I'll investigate and see if this is a 
problem on the binutils or the kernel side.  I may need to ask for .config 
in the process.  If you have problems with older binutils, then I just 
*might* be able to provide advice or a workaround, but my capabilities 
beyond that may be limited, I'm a limited resource after all.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ