On 09/11/2017 07:58 AM, Bin Meng wrote: > 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 >
Hello Bin, I found this comment in the code: https://sourceware.org/viewvc/src/bfd/elf64-x86-64.c?view=markup#l2921 Don't allocate .got.plt section if there are no GOT nor PLT entries and there is no reference to _GLOBAL_OFFSET_TABLE_. It was introduced in 2010. I have no clue how to investigate this further. Best regards Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
