This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Jie Zhang <zhangjie@magima.com.cn> writes:[ 1] .text PROGBITS 60004000 000c10 000e44 00 WAX 0 0 4
When using -Obinary option, objcopy will essentially produce a memory dump of the contents of the input object file. Although the file size of the segment containing .bss is zero, its memory size is not. In the above file, when the size of .data isn't zero, it doesn't matter. The memory dump will actually start at 60003400. When the size of .data is zero, the start address depends on the memory size of .bss if there is no space left for .bss at the start of the binary file. The memory size of .bss differ from file to file. It will be difficult to have an automatic method to load the binary file into memory, since we will have to figure out the start address of the memory dump.Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000074 0x60003400 0x60003400 0x00000 0x00064 RW 0x4
LOAD 0x000074 0x60003464 0x60003464 0x019e0 0x019e0 RWE 0x4
I expect that the memory dump will start at 60003400, but actually it
starts at 60003464. It seems that objcopy does not actually copy .bss
section. But .bss section is in a LOAD type segment and should, I
think, be part of the memory dump.
.bss has NOBITS, so there is no data to put into the binary file. It's true that .bss is in a LOAD type segment, but the file size of that segment is zero.
When not using an operating system loader, it's normal for a program to have to zero out the BSS in the startup code. In most cases, this is more efficient than copying a bunch of zeroes around.
Ian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |