Question concerning objcopy an elf file into a raw binary file

Question concerning objcopy an elf file into a raw binary file

[Jie Zhang]

Hello,
I use objcopy to get a raw binary file from an elf file. Here are the 
section headers and program headers:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg 
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      
0   0  0
  [ 1] .text             PROGBITS        60004000 000c10 000e44 00 WAX  
0   0  4
  [ 2] .data             PROGBITS        60003400 000074 000000 00  WA  
0   0  1
  [ 3] .bss              NOBITS          60003400 000074 000064 00  WA  
0   0  4
  [ 4] .rodata           PROGBITS        60003464 000074 0000ac 00   A  
0   0  4
  [ 5] .comment          PROGBITS        00000000 001a54 00001b 00      
0   0  1
  [ 6] .shstrtab         STRTAB          00000000 001a6f 00003d 00      
0   0  1
  [ 7] .symtab           SYMTAB          00000000 001c14 000330 10      
8   c  4
  [ 8] .strtab           STRTAB          00000000 001f44 000331 00      
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

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

 Section to Segment mapping:
  Segment Sections...
   00     .bss
   01     .text .rodata

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.

Any thoughts on this issue? Thanks a lot!

Jie

Re: Question concerning objcopy an elf file into a raw binary file

[Ian Lance Taylor]

Jie Zhang <zhangjie@magima.com.cn> writes:

>   [ 3] .bss              NOBITS          60003400 000074 000064 00  WA
> 0   0  4

> 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

Re: Question concerning objcopy an elf file into a raw binary file

[Jie Zhang]

Ian Lance Taylor wrote:

>Jie Zhang <zhangjie@magima.com.cn> writes:
>  
>
 [ 1] .text             PROGBITS        60004000 000c10 000e44 00 WAX  
0   0  4
 [ 2] .data             PROGBITS        60003400 000074 000000 00  WA  
0   0  1
 [ 3] .bss              NOBITS          60003400 000074 000064 00  WA  
0   0  4
 [ 4] .rodata           PROGBITS        60003464 000074 0000ac 00   A  
0   0  4

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

In this case, leaving out a space as large as the memory size of .bss at 
the beginning of the binary file can make thing much easier.

Jie

Re: Question concerning objcopy an elf file into a raw binary file

[Ian Lance Taylor]

Jie Zhang <zhangjie@magima.com.cn> writes:

> In this case, leaving out a space as large as the memory size of .bss
> at the beginning of the binary file can make thing much easier.

Understood, but it doesn't work that way, and it isn't going to
change.  Most people prefer it to work the way it works today.

You can use a linker script to force the .bss section into the .data
section.  You may have to add a BYTE(0) or something to force the
.data section to be allocated, if you don't have any data.

Ian