[U-Boot] Building qemu-x86_64_defconfig fails: u-boot-spl-nodtb.bin of 4, 293, 642, 704 bytes

[Bin Meng]

Hi Heinrich,

On Mon, Sep 11, 2017 at 1:07 PM, Heinrich Schuchardt <xypron.glpk at 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.glpk at 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 <schwab at 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