Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Guenter Roeck]

Hi folks,

building mips images with a consistent infrastructure is becoming more and more difficult.
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").
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.

Thanks,
Guenter

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Maciej W. Rozycki]

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

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Guenter Roeck]

On Fri, May 20, 2016 at 02:21:34PM +0100, Maciej W. Rozycki wrote:
> 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.
> 

binutils 2.25, any kernel supporting it (3.18+), mips:allnoconfig:

  CC      arch/mips/mm/sc-ip22.o

{standard input}: Assembler messages:
{standard input}:131: Error: number (0x9000000080000000) larger than 32 bits
{standard input}:154: Error: number (0x9000000080000000) larger than 32 bits
{standard input}:191: Error: number (0x9000000080000000) larger than 32 bits

There is assembler code in arch/mips/mm/sc-ip22.c which first sets "mips3"
(which I think is 32 bit) and then issues "dli\t$1, 0x9000000080000000\n\t",
which apparently the assembler in binutils 2.25 doesn't like.

---

binutils 2.24, mips:defconfig or mips:allnoconfig; Kernel 3.2.y or 3.4.y

arch/mips/mm/page.c:88:6: error: 'clear_page' alias in between function and variable is not supported
void clear_page(void *page) __attribute__((alias("clear_page_array")));

[there are several of those messages]

I can not really comment on microMIPS or not. Maybe some configurations do work
with binutils 2.24 and kernel versions 3.2 or 3.4. If so, I have not been able
to find them.

Builds with binutils 2.22 on recent kernels fail on and off (there was a failure
in -next a few days ago which has since then be fixed). Overall using it as
"default" builder is by now too fragile, which is why I dropped it as baseline
version. I now only build defconfig and allnoconfig with it as basic sanity test.

For qemu tests, I ended up using a combination of binutils 2.22, 2.24, and 2.25
depending on the kernel version. Previously I only used 2.22, but again that
is by now too risky. I can not just use 2.25 since it isn't supported in older
kernels (plus mips-gcc in Poky 2.0 seems to be buggy for mipsel64, or maybe that
compiler and qemu don't like each other), I can not just use 2.24 because it
isn't supported in 3.2 and 3.4, and I don't want to use 2.22 for recent kernels
since all tests may end up failing because some feature only available in later
versions of binutils was added to the kernel. 

Guenter

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Maciej W. Rozycki]

On Fri, 20 May 2016, Guenter Roeck wrote:

> >  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.
> > 
> 
> binutils 2.25, any kernel supporting it (3.18+), mips:allnoconfig:
> 
>   CC      arch/mips/mm/sc-ip22.o
> 
> {standard input}: Assembler messages:
> {standard input}:131: Error: number (0x9000000080000000) larger than 32 bits
> {standard input}:154: Error: number (0x9000000080000000) larger than 32 bits
> {standard input}:191: Error: number (0x9000000080000000) larger than 32 bits
> 
> There is assembler code in arch/mips/mm/sc-ip22.c which first sets "mips3"
> (which I think is 32 bit) and then issues "dli\t$1, 0x9000000080000000\n\t",
> which apparently the assembler in binutils 2.25 doesn't like.

 This has been recently fixed:

commit 22522f880a8e17a17c4f195796ec89caece7652b
Author: Maciej W. Rozycki <macro@imgtec.com>
Date:   Fri Apr 22 01:04:52 2016 +0100

    MIPS/GAS: Fix an ISA override not lifting ABI restrictions

This regression had slipped through due to the lack of test coverage 
(which has now been addressed).

> ---
> 
> binutils 2.24, mips:defconfig or mips:allnoconfig; Kernel 3.2.y or 3.4.y
> 
> arch/mips/mm/page.c:88:6: error: 'clear_page' alias in between function and variable is not supported
> void clear_page(void *page) __attribute__((alias("clear_page_array")));
> 
> [there are several of those messages]

 This is a GCC error and not one from binutils (GAS or LD), so I can't 
help with this, sorry.  Since this looks like a regression to me, you may 
try asking at the <gcc@gcc.gnu.org> mailing list, to get a clarification 
at least.

> I can not really comment on microMIPS or not. Maybe some configurations do work
> with binutils 2.24 and kernel versions 3.2 or 3.4. If so, I have not been able
> to find them.

 That's what written in:

commit c022630633624a75b3b58f43dd3c6cc896a56cff
Author: Steven J. Hill <sjhill@mips.com>
Date:   Fri Jul 6 21:56:01 2012 +0200

    MIPS: Refactor 'clear_page' and 'copy_page' functions.

-- which is what I based my reply on.  It looks like however, there has 
been an independent generic change made to GCC, which caused the `alias' 
attribute to stop working regardless of the microMIPS vs regular MIPS 
problem (which BTW has resulted from the need to set the ISA bit, i.e. bit 
#0 of code addresses, in microMIPS code references).

> Builds with binutils 2.22 on recent kernels fail on and off (there was a failure
> in -next a few days ago which has since then be fixed). Overall using it as
> "default" builder is by now too fragile, which is why I dropped it as baseline
> version. I now only build defconfig and allnoconfig with it as basic sanity test.

 I can't comment on intermittent failures unless I have a proper error 
report I'm afraid.

> For qemu tests, I ended up using a combination of binutils 2.22, 2.24, and 2.25
> depending on the kernel version. Previously I only used 2.22, but again that
> is by now too risky. I can not just use 2.25 since it isn't supported in older
> kernels (plus mips-gcc in Poky 2.0 seems to be buggy for mipsel64, or maybe that
> compiler and qemu don't like each other), I can not just use 2.24 because it
> isn't supported in 3.2 and 3.4, and I don't want to use 2.22 for recent kernels
> since all tests may end up failing because some feature only available in later
> versions of binutils was added to the kernel. 

 This is too vague for me to make any conclusions I'm afraid.  I'm not 
sure what you mean by "[2.24] isn't supported in 3.2 and 3.4" for example.  
Please elaborate and provide examples of errors you've seen and I'll try 
to help.

 Overall given commit 22522f880a8e quoted above your best bet might be 
either using current binutils master (until 2.26 is released later this 
year) or backporting the fix to an older release of choice.

  Maciej

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

Hi Guenter,

On Fri, May 20, 2016 at 10:31:39AM -0700, Guenter Roeck wrote:
> Builds with binutils 2.22 on recent kernels fail on and off (there was a failure
> in -next a few days ago which has since then be fixed). Overall using it as
> "default" builder is by now too fragile, which is why I dropped it as baseline
> version. I now only build defconfig and allnoconfig with it as basic sanity test.
> 
> For qemu tests, I ended up using a combination of binutils 2.22, 2.24, and 2.25
> depending on the kernel version. Previously I only used 2.22, but again that
> is by now too risky. I can not just use 2.25 since it isn't supported in older
> kernels (plus mips-gcc in Poky 2.0 seems to be buggy for mipsel64, or maybe that
> compiler and qemu don't like each other), I can not just use 2.24 because it
> isn't supported in 3.2 and 3.4, and I don't want to use 2.22 for recent kernels
> since all tests may end up failing because some feature only available in later
> versions of binutils was added to the kernel. 

FWIW, we've already made some effort to make versions of binutils
lacking more recent features continue to work (with a very small
performance hit), so I do think there is still value in having at least
some build testing with these toolchain versions, e.g.:

- MSA (binutils < 2.25)
- XPA (binutils < 2.25, in fact we don't take advantage of binutils
  support at all right now)
- VZ (binutils < 2.24... sorry for breaking that btw!)

Certain configurations use more invasive features where no attempt is
made to support older toolcahin versions though, but these are normally
along the lines of needing a whole different/incompatible kernel, so
tends to be a very concious decision on the part of the user e.g.:

- EVA (binutils < 2.24, nothing technically preventing it though)
- microMIPS (binutils < 2.22, requires full toolcahin support)
- MIPS R6 (binutils < 2.25, requires full toolchain support)

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Sun, 2016-05-15 at 19:56 -0700, Guenter Roeck wrote:
[...]
> 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").
> 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.

I'm finally queueing this up for 3.2.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Guenter Roeck]

On 10/08/2017 11:12 AM, Ben Hutchings wrote:
> On Sun, 2016-05-15 at 19:56 -0700, Guenter Roeck wrote:
> [...]
>> 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").
>> 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.
> 
> I'm finally queueing this up for 3.2.
> 
> Ben.
> 

mipsel images in 3.2.y-queue are now crashing for me. Should I have a look ?

Guenter

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Guenter Roeck]

On 10/08/2017 11:49 AM, Guenter Roeck wrote:
> On 10/08/2017 11:12 AM, Ben Hutchings wrote:
>> On Sun, 2016-05-15 at 19:56 -0700, Guenter Roeck wrote:
>> [...]
>>> 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").
>>> 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.
>>
>> I'm finally queueing this up for 3.2.
>>
>> Ben.
>>
> 
> mipsel images in 3.2.y-queue are now crashing for me. Should I have a look ?
> 
Turns out the culprit is qemu. I had switched from qemu 2.9 to qemu 2.10.
Something has changed in qemu that causes a qemu boot failure with 3.2 mipsel
(but not in more recent kernels). I'll switch back to qemu 2.9 for the affected
builds.

Guenter

Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Sun, 2017-10-08 at 12:01 -0700, Guenter Roeck wrote:
> On 10/08/2017 11:49 AM, Guenter Roeck wrote:
> > On 10/08/2017 11:12 AM, Ben Hutchings wrote:
> > > On Sun, 2016-05-15 at 19:56 -0700, Guenter Roeck wrote:
> > > [...]
> > > > 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").
> > > > 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.
> > > 
> > > I'm finally queueing this up for 3.2.
> > > 
> > > Ben.
> > > 
> > 
> > mipsel images in 3.2.y-queue are now crashing for me. Should I have a look ?
> > 
> 
> Turns out the culprit is qemu. I had switched from qemu 2.9 to qemu 2.10.
> Something has changed in qemu that causes a qemu boot failure with 3.2 mipsel
> (but not in more recent kernels). I'll switch back to qemu 2.9 for the affected
> builds.

Thanks.  I did notice these failures but didn't think they were related
to the few MIPS patches in the 3.2 queue.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]