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

newer
[U-Boot] [PATCH] dm: video: Add...

older
Re: [U-Boot] mv88e61xx autoneg...

Heinrich Schuchardt

10 Sep 2017 10 Sep '17

6:36 a.m.

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

Show replies by date

Bin Meng

10 Sep 10 Sep

12:52 p.m.

Hi Heinrich,

On Sun, Sep 10, 2017 at 12:36 PM, Heinrich Schuchardt xypron.glpk@gmx.de 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

I cannot reproduce this on Ubuntu 16.04.

$ gcc --version gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

$ objcopy --version GNU objcopy (GNU Binutils for Ubuntu) 2.26.1

Regards, Bin

Heinrich Schuchardt

5:18 p.m.

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@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

Regards

Heinrich

Bin Meng

11 Sep 11 Sep

3:42 a.m.

Hi Heinrich,

On Sun, Sep 10, 2017 at 11:18 PM, Heinrich Schuchardt xypron.glpk@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@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

Heinrich Schuchardt

7:07 a.m.

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@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@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

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/5f1d9857a4bd7b629b58ac745001ceda04c... to https://github.com/xypron2/u-boot/commits/spl-fix

I just want to wait for Travis CI to complete before sending it.

Best regards

Heinrich

Bin Meng

7:58 a.m.

Hi Heinrich,

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

Heinrich Schuchardt

12 Sep 12 Sep

12:17 a.m.

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@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@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@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/5f1d9857a4bd7b629b58ac745001ceda04c... 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

2797

Age (days ago)

2798

Last active (days ago)

List overview

Download

6 comments

2 participants

tags (0)

participants (2)

Bin Meng
Heinrich Schuchardt