Arm: How does objcopy know which sections from an elf to include in a binary or ihex?

Question

I'm working on a project which involves parsing an arm elf file and extracting the sections from it.

There are obviously plenty of sections in an elf file which do not get loaded into flash, but I'm wondering how exactly objcopy knows which sections to include in a binary to be flashed directly into flash?

Take for example the following readelf of an arm elf file:

Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al

[ 0] NULL 00000000 000000 000000 00 0 0 0

[ 1] .isr_vector PROGBITS 08020000 010000 0001f8 00 WA 0 0 4

[ 2] .firmware_header_ PROGBITS 080201f8 0101f8 000004 00 WA 0 0 4

[ 3] .text PROGBITS 08020200 010200 01e11c 00 AX 0 0 64

[ 4] .ARM.extab PROGBITS 0803e31c 033a68 000000 00 W 0 0 1

[ 5] .exidx ARM_EXIDX 0803e31c 02e31c 000008 00 AL 3 0 4

[ 6] .ARM.attributes ARM_ATTRIBUTES 0803e324 033a68 000030 00 0 0 1

[ 7] .init_array INIT_ARRAY 0803e324 02e324 000008 04 WA 0 0 4

[ 8] .fini_array FINI_ARRAY 0803e32c 02e32c 000004 04 WA 0 0 4

[ 9] .firmware_header PROGBITS 0803e330 02e330 000008 00 WA 0 0 4

[10] .data PROGBITS 20000000 030000 0009c8 00 WA 0 0 8

[11] .RxDecripSection PROGBITS 200009c8 0309c8 000080 00 WA 0 0 4

[12] .RxarraySection PROGBITS 20000a48 030a48 0017d0 00 WA 0 0 4

[13] .TxDescripSection PROGBITS 20002218 032218 000080 00 WA 0 0 4

[14] .TxarraySection PROGBITS 20002298 032298 0017d0 00 WA 0 0 4

[15] .bss NOBITS 20003a68 033a68 045bc0 00 WA 0 0 8

[16] .heap PROGBITS 20049628 033a98 000000 00 W 0 0 1

[17] .reserved_for_sta PROGBITS 20049628 033a98 000000 00 W 0 0 1

[18] .battery_backed_s NOBITS 40024000 034000 00000c 00 WA 0 0 4

[19] .comment PROGBITS 00000000 033a98 000075 01 MS 0 0 1

[20] .debug_frame PROGBITS 00000000 033b10 001404 00 0 0 4

[21] .stab PROGBITS 00000000 034f14 000084 0c 22 0 4

[22] .stabstr STRTAB 00000000 034f98 000117 00 0 0 1

[23] .symtab SYMTAB 00000000 0350b0 009010 10 24 1646 4

[24] .strtab STRTAB 00000000 03e0c0 003dc8 00 0 0 1

[25] .shstrtab STRTAB 00000000 041e88 000132 00 0 0 1

Now, obviously quite a few of these sections (like .TxarraySection) are not loaded into flash. However, that section type is PROGBITS and it has a writable and allocated flag. This is no different than isr_vector, which is loaded but has the same type and flags. What am I missing here? Should I be looking in the program header?

Answer 1

The sections copied to binary are those with a nonzero size, containing the SHF_ALLOC flag, with a type not equal to NOBITS.

Answer 2

How sure are you that TxarraySection isn't resident in flash? My guess is that it is, but your system initialization ignores it on startup.

Here's what the objcopy man page has to say about what it's doing:

objcopy can be used to generate a raw binary file by using an output target of ‘binary’ (e.g., use -O binary). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file.

I have my own Cortex-M7 elf file that I used to test this. I can convert to binary using objcopy probably the same way you are:

objcopy -O binary in.axf out.bin

In my case the size of out.bin is 376480. I can then inspect the input ELF file using readelf probably the same way you are:

readelf -S in.axf

I get a list of sections similar to the ones you've shown. If I then go through and add up the sizes of everything that is of type PROGBITS which also includes an Alloc flag, it adds up to exactly 376480. As described, objcopy has simply gone through the list of allocated sections in order and copied them to the output.

In general objcopy is pretty "dumb" in the sense that it doesn't try to make any sophisticated decisions about what to include or exclude. There are flags you can use to explicitly include or exclude certain regions, but in general if you're working on a bare-metal platform, it's up to you to decide exactly how your flash image should be laid out.

Without knowing all of the details of your particular system it's very hard to know exactly how to answer your question, but the most important detail to highlight is that objcopy doesn't really know anything, it will blindly copy just about anything, which means in most cases if you're just using -O binary with no other guidance, you're probably ending up with junk in your flash image that you don't actually need or want.

Answer 3

The address tells you that it's in RAM, so unless your flash programmer can also handle SRAM, you can eliminate them that way. Ditto that's how you can handle debug symbols too, their addresses are zero.