All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Woerner <twoerner@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Tom Rini <trini@konsulko.com>, yocto@yoctoproject.org
Subject: Re: [meta-rockchip][PATCH] u-boot-rockchip: fix for binutils-2.28
Date: Thu, 9 Mar 2017 00:01:12 -0500	[thread overview]
Message-ID: <20170309050112.GB4366@linux-uys3> (raw)
In-Reply-To: <20170309005103.GC24752@haswell>

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.


  reply	other threads:[~2017-03-09  5:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-08 17:31 [meta-rockchip][PATCH] u-boot-rockchip: fix for binutils-2.28 Trevor Woerner
2017-03-08 23:28 ` Tom Rini
2017-03-08 23:42   ` Khem Raj
2017-03-09  0:01     ` Tom Rini
2017-03-09  0:51       ` Khem Raj
2017-03-09  5:01         ` Trevor Woerner [this message]
2017-03-09  5:33           ` Khem Raj
2017-03-09 14:19             ` Trevor Woerner
2017-03-09  4:42   ` Trevor Woerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170309050112.GB4366@linux-uys3 \
    --to=twoerner@gmail.com \
    --cc=raj.khem@gmail.com \
    --cc=trini@konsulko.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.