Hi Heinrich, On Mon, Sep 11, 2017 at 1:07 PM, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > On 09/11/2017 03:42 AM, Bin Meng wrote: >> Hi Heinrich, >> >> On Sun, Sep 10, 2017 at 11:18 PM, Heinrich Schuchardt >> <xypron.g...@gmx.de> wrote: >>> On 09/10/2017 06:36 AM, Heinrich Schuchardt wrote: >>>> export BUILD_ROM=y >>>> make mrproper >>>> make qemu-x86_64_defconfig >>>> make >>>> >>>> results in a file u-boot-spl-nodtb.bin of 4,293,642,704 bytes >>>> for git HEAD. >>>> >>>> The problematic statement is >>>> >>>> objcopy -O binary -R .start16 -R .resetvec \ >>>> spl/u-boot-spl spl/u-boot-spl-nodtb.bin >>>> >>>> spl/u-boot-spl has 2,385,168 bytes. >>>> >>>> My system is Debian Stretch x86_64. >>>> GNU objcopy (GNU Binutils for Debian) 2.28 >>>> >>>> objdump -h spl/u-boot-spl >>>> shows that the section .start16 and .resetvec exist. >>>> >>>> I have created an upstream bug report >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22120 >>>> >>>> Best regards >>>> >>>> Heinrich >>>> >>> >>> This seems not to be a bug in objcopy: >>> >>> --- Comment #2 from Andreas Schwab <sch...@linux-m68k.org> --- >>> This is not a bug. The sections to be copied cover an address range from >>> 00120000 to FFFDC9D0, and the binary format cannot represent holes. >>> >>> 3 .data 00000510 fffdc4c0 fffdc4c0 0000e4c0 2**5 >>> CONTENTS, ALLOC, LOAD, RELOC, DATA >>> 4 .got 00000004 00120000 00120000 00001000 2**2 >>> CONTENTS, ALLOC, LOAD, DATA >> >> So does this mean: upgrading to objcopy v2.28 will break qemu-x86_64? >> Could you talk to them why does the objcopy behavior change between >> versions? >> >> Regards, >> Bin >> > Hello Bin, > > using objcopy 2.25 does the same as 2.28: > > objcopy -O binary -R .start16 -R .resetvec \ > u-boot-spl u-boot-spl-nodtb.bin > > It creates the same 4G file when using the u-boot-spl file created on > Debian Stretch. But the u-boot-spl files are different on Debian Stretch > and Debian Jessie: > > On Debian Stretch > > objdump -h spl/u-boot-spl > > 3 .data 00000510 fffdc4c0 fffdc4c0 0000e4c0 2**5 > CONTENTS, ALLOC, LOAD, RELOC, DATA > 4 .got 00000004 00120000 00120000 00001000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .got.plt 0000000c 00120004 00120004 00001004 2**2 > CONTENTS, ALLOC, LOAD, DATA > 6 .bss 00000900 00120020 00120020 00000000 2**5 > ALLOC > > .got 0x0000000000120000 0x4 > .got 0x0000000000120000 0x4 arch/x86/cpu/start.o > > .got.plt 0x0000000000120004 0xc > .got.plt 0x0000000000120004 0xc arch/x86/cpu/start.o > 0x0000000000120004 _GLOBAL_OFFSET_TABLE_ > > On Debian Jessie > > objdump -h spl/u-boot-spl > > 3 .data 00000268 fffdca80 fffdca80 0000da80 2**4 > CONTENTS, ALLOC, LOAD, RELOC, DATA > 4 .bss 00000900 00120000 00120000 00000000 2**4 > ALLOC >
So it is not a behavior change of objcopy (v2.26->v2.28), but ld (v2.26->v.2.28)? Can you figure out why? > objcopy -O binary -R .start16 -R .resetvec \ > -R .got -R .got.plt u-boot-spl u-boot-spl-nodtb.bin > > creates a 51k file on both systems. > > got refers to global offset table > plt refers to procedure linkage table > > I have added patch > https://github.com/xypron2/u-boot/commit/5f1d9857a4bd7b629b58ac745001ceda04c85b8d > to > https://github.com/xypron2/u-boot/commits/spl-fix > > I just want to wait for Travis CI to complete before sending it. > Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
