Bug 22120 - objcopy -R creates 4G file
Summary: objcopy -R creates 4G file
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.28
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-10 04:30 UTC by Heinrich Schuchardt
Modified: 2017-09-10 07:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
File for testing (718.26 KB, application/octet-stream)
2017-09-10 04:35 UTC, Heinrich Schuchardt 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Heinrich Schuchardt 2017-09-10 04:30:59 UTC 
For a file spl/u-boot-spl of 2,385,168 bytes.

I run 

objcopy -O binary -R .start16 -R .resetvec \
  spl/u-boot-spl spl/u-boot-spl-nodtb.bin

The result is a file u-boot-spl-nodtb.bin of 4,293,642,704 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.

To reproduce run

git clone http://git.denx.de/u-boot.git
export BUILD_ROM=y
make mrproper
make qemu-x86_64_defconfig
make
Comment 1 Heinrich Schuchardt 2017-09-10 04:35:02 UTC 
Created attachment 10406 [details]
File for testing

objcopy -O binary -R .start16 -R .resetvec \
    u-boot-spl u-boot-spl-nodtb.bin

with the appended file shows the error.
Comment 2 Andreas Schwab 2017-09-10 06:56:55 UTC 
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.
Comment 3 Heinrich Schuchardt 2017-09-10 07:14:38 UTC 
On 09/10/2017 08:56 AM, schwab@linux-m68k.org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=22120
> 
> Andreas Schwab <schwab@linux-m68k.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|---                         |INVALID
> 
> --- 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.
> 
Thank you for the analysis.

Best regards

Heinrich