Ralf Baechle <ralf@xxxxxxxxxxxxxx> writes: > On Wed, Oct 28, 2015 at 09:02:43PM +0000, Matthew Fortune wrote: > > > Aaro Koskinen <aaro.koskinen@xxxxxx> 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
