Inspecting the contents of the ELF file
ELF files contain useful information. IAR Embedded Workbench is delivered with ielfdumprh850—the IAR ELF Dumper—a command line tool that analyzes the contents of ELF files. Much of this information might be intentionally stripped out or not generated by some tool sets, but using the IAR toolchain with default settings, you can get information about, for example:
Target hardware requirements—for example, byte order and hardware/software floating-point.
The application size, both in the file and when running on target hardware, available in segments, section sizes, and possibly symbols.
The resulting assembler code—the exact instructions to be executed.
ielfdumprh850can use symbols to tell code from data, to provide a usable disassembly.Debug symbols—the exact information available varies with the toolchain that produced the file, but for the IAR build tools, for example, the names of C/C++ source code files and functions are available.
The information can be retrieved as lists and tables in plain text, or in machine-readable JSON format. The JSON format contains descriptions of all fields and is recommended if you want explanations of the output. For information about using ielfdumprh850, see The IAR ELF Dumper—ielfdumprh850.
Note
To save space in the output, ielfdumprh850 does not output null values—instead the value will be omitted.
Estimating application memory usage
You can use ielfdumprh850 to estimate the amount of memory your application will use, but there are some factors you must be aware of. When trying to estimate the memory usage, comparing it with memory available on the target hardware, you cannot assume that if there are 400 bytes left, and an instruction is 4 bytes, you can fit exactly 100 more instructions onto the chip. Some of the most important reasons for why this is not generally the case are:
Fragmentation. Due to alignment restrictions and the need for some functions to reside in specific address areas, there are situations where memory, even when available, is fragmented and therefore cannot be used. You might have 1 kByte available in 32-byte chunks, and thus be unable to place even 100 continuous bytes anywhere.
Compression. To save space, ILINK will sometimes compress data, for example initializers. If and how this is performed depends on which type of compression that gives the best results. For this reason, the sizes of some sections in the ELF file might actually be smaller than the source data. This also makes size increases less predictable.
Even with correct information about current memory usage, it is difficult to predict the exact impact a change will have on future memory usage.