[U-Boot] [PATCH 1/1] spl: u-boot-spl-nodtb.bin: remove .got and .got.plt sections
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@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_. --- 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)
$(obj)/$(SPL_BIN)-nodtb.bin: $(obj)/$(SPL_BIN) FORCE $(call if_changed,objcopy)
On 12 Sep 2017, at 00:40, Heinrich Schuchardt xypron.glpk@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@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_.
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)
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?
$(obj)/$(SPL_BIN)-nodtb.bin: $(obj)/$(SPL_BIN) FORCE $(call if_changed,objcopy) -- 2.11.0
On 09/12/2017 01:19 AM, Dr. Philipp Tomsich wrote:
On 12 Sep 2017, at 00:40, Heinrich Schuchardt xypron.glpk@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@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_.
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)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
Heinrich
$(obj)/$(SPL_BIN)-nodtb.bin: $(obj)/$(SPL_BIN) FORCE $(call if_changed,objcopy) -- 2.11.0
Hi Heinrich,
On Tue, Sep 12, 2017 at 8:50 AM, Heinrich Schuchardt xypron.glpk@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@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@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?
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?
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, Bin
Hi,
On 12 September 2017 at 23:43, Bin Meng bmeng.cn@gmail.com wrote:
Hi Heinrich,
On Tue, Sep 12, 2017 at 8:50 AM, Heinrich Schuchardt xypron.glpk@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@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@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
participants (4)
-
Bin Meng -
Dr. Philipp Tomsich -
Heinrich Schuchardt -
Simon Glass