mierle

(1) Execution - A container describing how an OS can load and execute a binary

(2) Linking - A container with relocatable machine code; for the linker to assemble

(3) Metadata for debugging and other purposes like stack traces

Program headers describe "segments". Segments are for the execution time view of the ELF. They describe the parts of the file to load into memory regions, and the execution entry address. The program headers are what are read by the OS when running "./my_executable". The segments don't always have names. Also, it is confusing that "sections" and "segments" mean very different things, but that's just how it is.

Thus, program headers (and the segments they describe) are for #1 - Execution.

Sections are a link-time construct, leveraged by the linker, to decide how to allocate functions and data to the execution segments (via sections). Intermediate ELF object files contain relocatable code, where the code is allocated to sections (you can manually specify them if you want). Example sections include ".text", which is executable code; ".bss" which is zero-initialized static variables; ".data" which is pre-initialized static variables, and so on. You can see an example of sections being allocated to segments in this thoroughly described linker script [1]. Sections are mostly ignored during program execution.

Thus, section headers (and the sections they describe) are for #2 - Linking.

You aren't alone in not knowing these details about ELF. It wasn't until I got into the embedded space that I dug deep to understand linking and loading, linker scripts, and executable formats. These details are important to understand for microcontrollers since you may need to carefully allocate code to physical addresses that have faster memory (e.g. core coupled RAM), or put code in flash. In some cases you execute code directly out of flash (so must tell the linker that including physical addresses); but in other cases, you might need to load code into RAM (manually, there is no OS!) from flash since executing out of flash can be slow. On desktops and servers, it's rare to change (or even know about) linker scripts.

The "pw watch" command is an integrated watcher that can detect file changes from e.g. vim, then re-build, re-flash your device, and re-run tests according to the dependency graph. I use 2 or 3 STM32F429i Discovery boards to run tests in parallel.

If you're curious, we're giving a workshop [4] at Hackaday's Remoticon; feel free to join or watch the recording after it's up.

After reading this book, I found myself digging through earnings reports to look for signs of shenanigans, and have found cases that raise my armchair-accountant eyebrows.