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

[Heinrich Schuchardt]

On 09/11/2017 07:58 AM, Bin Meng wrote:
> 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
> 

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