[Bug binutils/24984] New: Objcopy -I binary --rename-section reserves space for input file, but doesn't include file's contents in .o file
https://sourceware.org/bugzilla/show_bug.cgi?id=24984 Bug ID: 24984 Summary: Objcopy -I binary --rename-section reserves space for input file, but doesn't include file's contents in .o file Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: antonone+sourceware at gmail dot com Target Milestone: --- Steps to reproduce: # 1. Create a 500MB file with random data in it $ dd if=/dev/urandom of=hugefile.bin bs=1M count=500 # 2. Create an object file that will include this file above, use the --rename-section option to put it into a new section: $ objcopy -I binary -B i386 -O elf64-x86-64 --rename-section .data=.CustomData,readonly /bin/ls test.o # 3. Open test.o in a hexeditor: observe that 99% of the file is all zeroes, instead of the content of hugefile.bin. At the same time, test.o has a proper file size. $ 4. Verify the contents of the output file. Notice the huge gap between 0x30 and 0x1f400050, meaning all data in this range is all zeroes: $ cat dst.o | xxd | grep -v " " : 7f45 4c46 0201 0100 .ELF 0010: 0100 3e00 0100 ..>. 0020: 3001 401f 0.@. 0030: 4000 4000 0500 0400 @.@. 1f400050: 0300 0100 1f400070: 0100 1000 0100 I've done the same steps on FreeBSD, which uses objcopy from elftoolchain, and it works correctly. The objcopy tool from binutils works correctly when not using the --rename-section option, but it also should work correctly with the --rename-section option. I've checked this on 2.32, as well as I've compiled by own objcopy v2.32.51.20190909, and the bug is still there. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24984] Objcopy -I binary --rename-section reserves space for input file, but doesn't include file's contents in .o file
https://sourceware.org/bugzilla/show_bug.cgi?id=24984 --- Comment #2 from Grzegorz Antoniak --- Well, lack of documentation for those section flags doesn't help with using them properly. Adding 'contents' to section flags indeed copies the file's contents to the object file, and resolves my problem. But if I won't specify contents, so I indicate the section has no contents, shouldn't the section size be zero? Because without the 'contents' flag, section size is 500MB. This can be interpreted as 500MB of byte 0x00. It looks like a content to me. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24984] Objcopy -I binary --rename-section reserves space for input file, but doesn't include file's contents in .o file
https://sourceware.org/bugzilla/show_bug.cgi?id=24984 --- Comment #4 from Grzegorz Antoniak --- Okay, I understand that ".bss" has a non-zero virtual size, and a zero physical size (that means, there is no file data inside the file for this section). But when I mark ".CustomData" as no-content, I'm ending up having the file content in my executable file, consisting of 0x00 bytes. My binary has a ~500mb size. Most of this space is assigned to a section which is marked as no-content. So ".CustomData" has a non-zero virtual size and a non-zero physical size while being marked as no-content. Shouldn't ".CustomData" be build like ".bss" is built when I don't specify the "content" flag? So, shouldn't it be just a section declaration in the section header without the actual space reservation in the executable file? Because currently the physical space reservation for this section exists in the file. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
