FYI: old OCTEON bootloaders and .MIPS.abiflags

FYI: old OCTEON bootloaders and .MIPS.abiflags

[Aaro Koskinen]

Hi,

Current binutils adds .MIPS.abiflags section to the kernel vmlinux.

This seems break the boot on some old (buggy) OCTEON bootloaders:

	ELF file is 64 bit
	Attempting to allocate memory for ELF segment: addr: 0xffffffff816e67f0 (adjusted to: 0x00000000016e67f0), size 0x18
	Allocated memory for ELF segment: addr: 0xffffffff816e67f0, size 0x18
	Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to: 0x0000000001100000), size 0x1b86360
	Error allocating memory for elf image!
	## ERROR loading File!

The workaround is to remove the .MIPS.abiflags with "strip" - I guess that
is safe for the kernel... Not sure if there is nothing much else to be
done, and already a similar hack needs to be done for the .notes section.

I just wanted to post this in case some else faces the same issue.

A.

RE: old OCTEON bootloaders and .MIPS.abiflags

[Matthew Fortune]

Aaro Koskinen <aaro.koskinen@iki.fi> writes:
> Current binutils adds .MIPS.abiflags section to the kernel vmlinux.
> 
> This seems break the boot on some old (buggy) OCTEON bootloaders:
> 
> 	ELF file is 64 bit
> 	Attempting to allocate memory for ELF segment: addr: 0xffffffff816e67f0 (adjusted to:
> 0x00000000016e67f0), size 0x18
> 	Allocated memory for ELF segment: addr: 0xffffffff816e67f0, size 0x18
> 	Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> 0x0000000001100000), size 0x1b86360
> 	Error allocating memory for elf image!
> 	## ERROR loading File!
> 
> The workaround is to remove the .MIPS.abiflags with "strip" - I guess that
> is safe for the kernel... Not sure if there is nothing much else to be
> done, and already a similar hack needs to be done for the .notes section.
> 
> I just wanted to post this in case some else faces the same issue.

It seems reasonably sensible to /DISCARD/ the .MIPS.abiflags section in the kernel link
scripts as I don't think the kernel needs that information for any purpose. I assume
.reginfo is discarded as well at some point.

Matthew

Re: old OCTEON bootloaders and .MIPS.abiflags

[Ralf Baechle]

On Wed, Oct 28, 2015 at 09:02:43PM +0000, Matthew Fortune wrote:

> Aaro Koskinen <aaro.koskinen@iki.fi> writes:
> > Current binutils adds .MIPS.abiflags section to the kernel vmlinux.
> > 
> > This seems break the boot on some old (buggy) OCTEON bootloaders:
> > 
> > 	ELF file is 64 bit
> > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff816e67f0 (adjusted to:
> > 0x00000000016e67f0), size 0x18
> > 	Allocated memory for ELF segment: addr: 0xffffffff816e67f0, size 0x18
> > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> > 0x0000000001100000), size 0x1b86360
> > 	Error allocating memory for elf image!
> > 	## ERROR loading File!
> > 
> > The workaround is to remove the .MIPS.abiflags with "strip" - I guess that
> > is safe for the kernel... Not sure if there is nothing much else to be
> > done, and already a similar hack needs to be done for the .notes section.
> > 
> > I just wanted to post this in case some else faces the same issue.
> 
> It seems reasonably sensible to /DISCARD/ the .MIPS.abiflags section in the kernel link
> scripts as I don't think the kernel needs that information for any purpose. I assume
> .reginfo is discarded as well at some point.

Historically discarding .reginfo didn't work because it is generated
by ld after it has generated all the output sections according to the
linker script.  So no matter what, one always ended up with a .reginfo.
This has been fixed at some point but I'm concerned the same behaviour
might have existed for .MIPS.abiflags as well and versions that do the
same thing with .MIPS.abiflags might still be around.

  Ralf

RE: old OCTEON bootloaders and .MIPS.abiflags

[Matthew Fortune]

Ralf Baechle <ralf@linux-mips.org> writes:
> On Wed, Oct 28, 2015 at 09:02:43PM +0000, Matthew Fortune wrote:
> 
> > Aaro Koskinen <aaro.koskinen@iki.fi> writes:
> > > Current binutils adds .MIPS.abiflags section to the kernel vmlinux.
> > >
> > > This seems break the boot on some old (buggy) OCTEON bootloaders:
> > >
> > > 	ELF file is 64 bit
> > > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff816e67f0 (adjusted to:
> > > 0x00000000016e67f0), size 0x18
> > > 	Allocated memory for ELF segment: addr: 0xffffffff816e67f0, size 0x18
> > > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> > > 0x0000000001100000), size 0x1b86360
> > > 	Error allocating memory for elf image!
> > > 	## ERROR loading File!
> > >
> > > The workaround is to remove the .MIPS.abiflags with "strip" - I guess that
> > > is safe for the kernel... Not sure if there is nothing much else to be
> > > done, and already a similar hack needs to be done for the .notes section.
> > >
> > > I just wanted to post this in case some else faces the same issue.
> >
> > It seems reasonably sensible to /DISCARD/ the .MIPS.abiflags section in the kernel link
> > scripts as I don't think the kernel needs that information for any purpose. I assume
> > .reginfo is discarded as well at some point.
> 
> Historically discarding .reginfo didn't work because it is generated
> by ld after it has generated all the output sections according to the
> linker script.  So no matter what, one always ended up with a .reginfo.
> This has been fixed at some point but I'm concerned the same behaviour
> might have existed for .MIPS.abiflags as well and versions that do the
> same thing with .MIPS.abiflags might still be around.

From the first implementation of .MIPS.abiflags the linker does not invent this section
other than by merging input sections called .MIPS.abiflags so if the input sections
are DISCARD'd then you will never see a .MIPS.abiflags output section nor the associated
program header.

I'm 99% sure of the above.

Matthew

RE: old OCTEON bootloaders and .MIPS.abiflags

[Matthew Fortune]

Ralf Baechle <ralf@linux-mips.org> writes:
> On Wed, Oct 28, 2015 at 09:02:43PM +0000, Matthew Fortune wrote:
> 
> > Aaro Koskinen <aaro.koskinen@iki.fi> writes:
> > > Current binutils adds .MIPS.abiflags section to the kernel vmlinux.
> > >
> > > This seems break the boot on some old (buggy) OCTEON bootloaders:
> > >
> > > 	ELF file is 64 bit
> > > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff816e67f0 (adjusted to:
> > > 0x00000000016e67f0), size 0x18
> > > 	Allocated memory for ELF segment: addr: 0xffffffff816e67f0, size 0x18
> > > 	Attempting to allocate memory for ELF segment: addr: 0xffffffff81100000 (adjusted to:
> > > 0x0000000001100000), size 0x1b86360
> > > 	Error allocating memory for elf image!
> > > 	## ERROR loading File!
> > >
> > > The workaround is to remove the .MIPS.abiflags with "strip" - I guess that
> > > is safe for the kernel... Not sure if there is nothing much else to be
> > > done, and already a similar hack needs to be done for the .notes section.
> > >
> > > I just wanted to post this in case some else faces the same issue.
> >
> > It seems reasonably sensible to /DISCARD/ the .MIPS.abiflags section in the kernel link
> > scripts as I don't think the kernel needs that information for any purpose. I assume
> > .reginfo is discarded as well at some point.
> 
> Historically discarding .reginfo didn't work because it is generated
> by ld after it has generated all the output sections according to the
> linker script.  So no matter what, one always ended up with a .reginfo.
> This has been fixed at some point but I'm concerned the same behaviour
> might have existed for .MIPS.abiflags as well and versions that do the
> same thing with .MIPS.abiflags might still be around.

Re: old OCTEON bootloaders and .MIPS.abiflags

[Ralf Baechle]

On Thu, Oct 29, 2015 at 10:15:01PM +0000, Matthew Fortune wrote:

> >From the first implementation of .MIPS.abiflags the linker does not invent this section
> other than by merging input sections called .MIPS.abiflags so if the input sections
> are DISCARD'd then you will never see a .MIPS.abiflags output section nor the associated
> program header.
> 
> I'm 99% sure of the above.

Great.

Aaro is going to resubmit this patch with some additional changes suggested
by David Daney on IRC so I'm going to drop this patch.

  Ralf