CODEWITHSUNDEEP
elfstm32
Randomblue
Randomblue

Reputation: 116353

Size of ELF file vs size in RAM

I have an STM32 onto which I load ELF files in RAM (using OpenOCD and JTAG). So far, I haven't really been paying attention to the size of the ELF files that I load.

Normally, when I compile an ELF file that is too large for my board (my board has 128KB of RAM onto which the executable can be loaded) the linker complains (in the linker script I specify the size of the RAM).

Now that I notice the size of the outputted ELF file, I see that it is 261KB, and yet the linker has not complained!

Why is my ELF file so large, but my linker is fine with it? Is the ELF file on the host loaded exactly on the board?

Upvotes: 2

Views: 3703

Answers (2)

gg99
gg99

Reputation: 656

using the utility arm-none-eabi-size you can get a better picture of what actually gets used on the chip. The -A option will breakdown the size by section.
The relevant sections to look at when it comes to RAM are .data, .bss (static ram usage) and .heap (the heap: dynamic memory allocation by your program).
Roughly speaking, as long as the static ram size is below the RAM number from the datasheet, you should be able to run something on the chip and the linker shouldn't complain - your heap usage will then depends on your program.

Note: .text would be what needs to fit in the flash (the code).

example: arm-none-eabi-size -A your-elf-file.elf

Sample output:

section              size        addr
.mstack              2048   536870912
.pstack              2304   536872960
.nocache               32   805322752
.eth                    0   805322784
.vectors              672   134217728
.xtors                 68   134610944
.text              162416   134611072
.rodata             23140   134773488
.ARM.exidx              8   134796628
.data                8380   603979776
.bss               101780   603988160
.ram0_init              0   604089940
.ram0                   0   604089940
.ram1_init              0   805306368
.ram1                   0   805306368
.ram2_init              0   805322784
.ram2                   0   805322784
.ram3_init              0   805339136
.ram3                   0   805339136
.ram4_init              0   939524096
.ram4                   0   939524096
.ram5_init              0   536875264
.ram5                   0   536875264
.ram6_init              0           0
.ram6                   0           0
.ram7_init              0   947912704
.ram7                   0   947912704
.heap              319916   604089940
.ARM.attributes        51           0
.comment               77           0
.debug_line        407954           0
.debug_info       3121944           0
.debug_abbrev      160701           0
.debug_aranges      14272           0
.debug_str         928595           0
.debug_loc         493671           0
.debug_ranges      146776           0
.debug_frame        51896           0
Total             5946701

Upvotes: 0

Jerry Coffin
Jerry Coffin

Reputation: 490408

No -- ELF contains things like relocation records that don't get loaded. It can also contain debug information (typically in DWARF format) that only gets loaded by a debugger.

You might want to use readelf to give you an idea of what one of your ELF files actually contains. You probably don't want to do it all the time, but doing it at least a few times to get some idea of what's there can give a much better idea of what you're dealing with.

readelf is part of the binutils package; chances are pretty decent you already have a copy that came with your other development tools.

If you want to get into even more detail, Googling for something like "ELF Format" should turn up lots of articles. Be aware, however, that ELF is a decidedly non-trivial format. If you decide you want to understand all the details, it'll take quite a bit of time and effort.

Upvotes: 5

Related Questions