[U-Boot] [PATCH 1/1] spl: u-boot-spl-nodtb.bin: remove .got and .got.plt sections

Simon Glass sjg at chromium.org
Sun Sep 17 17:52:33 UTC 2017


Hi,

On 12 September 2017 at 23:43, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Heinrich,
>
> On Tue, Sep 12, 2017 at 8:50 AM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> On 09/12/2017 01:19 AM, Dr. Philipp Tomsich wrote:
>>>> On 12 Sep 2017, at 00:40, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>>>
>>>> For qemu-x86_64_defconfig on Debian Stretch
>>>> ld 2.28 creates a .got and a .got.plt section in
>>>> u-boot-spl.
>>>>
>>>> If we do not ignore these sections objcopy generates an
>>>> u-boot-spl-nodtb.bin file of 4 GiB which leads to
>>>> subsequent failure of the build process.
>>>>
>>>> According to
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22120#c2
>>>> objcopy can not generate files with holes.
>>>>
>>>> With the patch we can run qemu with the generated u-boot.rom.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>> ---
>>>> I ran the Travis CI tests with no error reported:
>>>> https://travis-ci.org/xypron2/u-boot/builds/274042004
>>>>
>>>> It is unclear to me why on Debian Stretch the .got and .got.plt sections
>>>> are generated. The problem does not exist on Debian Jessie which uses
>>>> binutils 2.25.
>>>>
>>>> I found this comment in the BFD code which describes under which
>>>> circumstances the .got.plt section is not generated:
>>>>
>>>> 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_.
>
> Can we have some binutils guys to look at this? Why does the behavior
> get changes between versions?

I don't understand why it would need this. Is it being generated
because of the multiboot_header code?

>
>>>> ---
>>>> scripts/Makefile.spl | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
>>>> index dd8065d87d..3b2d79d562 100644
>>>> --- a/scripts/Makefile.spl
>>>> +++ b/scripts/Makefile.spl
>>>> @@ -286,7 +286,8 @@ quiet_cmd_objcopy = OBJCOPY $@
>>>> cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
>>>>
>>>> OBJCOPYFLAGS_$(SPL_BIN)-nodtb.bin = $(SPL_OBJCFLAGS) -O binary \
>>>> -            $(if $(CONFIG_SPL_X86_16BIT_INIT),-R .start16 -R .resetvec)
>>>> +            $(if $(CONFIG_SPL_X86_16BIT_INIT), \
>>>> +            -R .start16 -R .resetvec -R .got -R .got.plt)
>>>
>
> Simon, would you take a look at this?

It would be better to figure out why it is being generated and stop
it. If it happens for SPL in x86_64 then presumably it happens for
32-bit U-Boot proper as well?

But in the absence of any root cause then I thin it is OK to add this
(but I'd like to see a comment in the code explaining it and
mentioning that binutils version xxx changed).

>
>>> If there is a non-empty .got, it can not be safely removed. The remaining code
>>> can (and will) reference data within the .got.
>>> Did you check the contents of the .got and where these are referenced from?
>>
>> This is from spl/u-boot-spl.map:
>>
>> .text           0x00000000fffd0000     0xa032
>>  *(.text*)
>>  .text          0x00000000fffd0000       0xcc arch/x86/cpu/start.o
>>                 0x00000000fffd0000                _x86boot_start
>>                 0x00000000fffd0020                _start
>>
>> .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_
>>
>> So in .got there is just the reference to the BIOS start address.
>> And .got.plt contains additionally a pointer to .got.
>>
>>> Did you check the contents of the .got and where these are referenced
>>> from?
>> It is unclear to me what additional information is needed and how it can
>> be extracted.

Regards,
Simon


More information about the U-Boot mailing list