Date: Thu, 9 Mar 2017 00:01:12 -0500
From: Trevor Woerner <twoerner@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Message-ID: <20170309050112.GB4366@linux-uys3>
References: <20170308173147.21841-1-twoerner@gmail.com>
	<20170308232821.GH19897@bill-the-cat>
	<20170308234200.GA24752@haswell>
	<20170309000105.GI19897@bill-the-cat>
	<20170309005103.GC24752@haswell>
MIME-Version: 1.0
In-Reply-To: <20170309005103.GC24752@haswell>
User-Agent: Mutt/1.6.0 (2016-04-01)
Cc: Tom Rini <trini@konsulko.com>, yocto@yoctoproject.org
Subject: Re: [meta-rockchip][PATCH] u-boot-rockchip: fix for binutils-2.28
Precedence: list
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Wed 2017-03-08 @ 04:51:04 PM, Khem Raj wrote:
> On 17-03-08 19:01:05, Tom Rini wrote:
> > On Wed, Mar 08, 2017 at 03:42:00PM -0800, Khem Raj wrote:
> > > On 17-03-08 18:28:21, Tom Rini wrote:
> > > > On Wed, Mar 08, 2017 at 12:31:47PM -0500, Trevor Woerner wrote:
> > > > 
> > > > > openembedded-core updated bintuils from 2.27 to 2.28 which causes u-boot to
> > > > > fail to compile:
> > > > > 
> > > > > 	arm-oe-linux-gnueabi-ld.bfd: u-boot: Not enough room for program headers, try linking with -N
> > > > > 
> > > > > Building with -N does fix the issue, so this patch simply adds that flag to
> > > > > the build so it succeeds.
> > > > > 
> > > > > This has been build-tested, as well as run-tested on the firefly.
> > > > > 
> > > > > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > > > 
> > > > Unless there's an immediate need I would ask holding off on this for a
> > > > bit, I want to track down why this is happening.
> > > 
> > > perhaps linker map files from 2.27 and 2.28 binutils will help to
> > > understand it
> > 
> > Nothing is standing out yet:
> > https://lists.denx.de/pipermail/u-boot/2017-March/283278.html
> > https://lists.denx.de/pipermail/u-boot/2017-March/283286.html
> 
> I see that .data.rel.ro are generated eventhough they are empty they
> appear to be in final link this section will hold constant variables
> that gcc sees and needs dynamic relocation, that probably is not
> relevant to u-boot since its linked stand-alone
> 
> Can you try to do just the final link with 2.28 and all built with 2.27
> and see if it still happens, want to rule out assembler

Okay.

Building with 2.28 (and letting it fail), then repeating the final link step
with 2.27 succeeds!

	$ arm-oe-linux-gnueabi-ld.bfd -v
	GNU ld (GNU Binutils) 2.27.0.20160806

	$ arm-oe-linux-gnueabi-ld.bfd   -pie  --gc-sections -Bstatic -Ttext 0x00000000 -o u-boot \
	  -T u-boot.lds arch/arm/cpu/armv7/start.o --start-group  arch/arm/cpu/built-in.o  \
	  arch/arm/cpu/armv7/built-in.o  arch/arm/lib/built-in.o  arch/arm/mach-rockchip/built-in.o \
	  board/firefly/firefly-rk3288/built-in.o  cmd/built-in.o  common/built-in.o  disk/built-in.o \
	  drivers/built-in.o  drivers/dma/built-in.o  drivers/gpio/built-in.o  drivers/i2c/built-in.o  \
	  drivers/mmc/built-in.o  drivers/mtd/built-in.o  drivers/mtd/onenand/built-in.o  \
	  drivers/mtd/spi/built-in.o  drivers/net/built-in.o  drivers/net/phy/built-in.o  \
	  drivers/pci/built-in.o  drivers/power/built-in.o  drivers/power/battery/built-in.o  \
	  drivers/power/domain/built-in.o  drivers/power/fuel_gauge/built-in.o  drivers/power/mfd/built-in.o  \
	  drivers/power/pmic/built-in.o  drivers/power/regulator/built-in.o  drivers/serial/built-in.o  \
	  drivers/spi/built-in.o  drivers/usb/common/built-in.o  drivers/usb/dwc3/built-in.o  \
	  drivers/usb/emul/built-in.o  drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o  \
	  drivers/usb/gadget/udc/built-in.o  drivers/usb/host/built-in.o  drivers/usb/musb-new/built-in.o  \
	  drivers/usb/musb/built-in.o  drivers/usb/phy/built-in.o  drivers/usb/ulpi/built-in.o  fs/built-in.o  \
	  lib/built-in.o  net/built-in.o  test/built-in.o  test/dm/built-in.o --end-group \
	  arch/arm/lib/eabi_compat.o  arch/arm/lib/lib.a -Map u-boot.map
	$ echo $?
	0

Looking at the top couple lines of a diff between the map files of a
binutils-2.27 build and this frankenbuild (both with SPL, neither with -N)
gives:

	--- 2.27-without-N/u-boot.map   2017-03-08 13:26:26.966147350 -0500
	+++ build-with-2.28-link-with-2.27/u-boot.map   2017-03-08 23:48:43.593173398 -0500
	@@ -5442,7 +5442,7 @@
	  .iplt          0x00000000000301a4        0x0 arch/arm/cpu/armv7/start.o
			 0x00000000000301a4                . = ALIGN (0x4)
	 
	-.rodata         0x00000000000301a8    0x134dc
	+.rodata         0x00000000000301a8    0x134b8
	  *(SORT(.rodata*))
	  .rodata.efi_boot_services
			 0x00000000000301a8       0xc8 lib/built-in.o
	@@ -5859,4836 +5859,4836 @@
	  .rodata.cb_erase.str1.1
			 0x0000000000033745       0x60 drivers/usb/gadget/built-in.o
	  .rodata.cb_getvar.str1.1
	-                0x00000000000337a5       0xfc drivers/usb/gadget/built-in.o
	-                                        0x10c (size before relaxing)
	+                0x00000000000337a5       0xea drivers/usb/gadget/built-in.o
	+                                         0xfa (size before relaxing)
	  .rodata.cb_oem.str1.1
	-                0x00000000000338a1       0x4e drivers/usb/gadget/built-in.o
	+                0x000000000003388f       0x4e drivers/usb/gadget/built-in.o
						  0x5c (size before relaxing)
[...snip!...]

	-.gnu            0x0000000000052680        0x0
	+.gnu            0x0000000000052658        0x0
	  *(.gnu*)
	  .gnu.version_d
	-                0x0000000000052680        0x0 arch/arm/cpu/armv7/start.o
	- .gnu.version   0x0000000000052680        0x0 arch/arm/cpu/armv7/start.o
	+                0x0000000000052658        0x0 arch/arm/cpu/armv7/start.o
	+ .gnu.version   0x0000000000052658        0x0 arch/arm/cpu/armv7/start.o
	  .gnu.version_r
	-                0x0000000000052680        0x0 arch/arm/cpu/armv7/start.o
	+                0x0000000000052658        0x0 arch/arm/cpu/armv7/start.o
	 
	 .ARM.exidx
	  *(.ARM.exidx*)

Everything after the first difference just appears to be the remainder of the
addresses off by those couple bytes.

If I'm reading this correctly, the size of the frankenbuild's .rodata section
is 0x24 (36d) bytes smaller than the full binutils-2.27 build.