In this lesson, you will learn how to inspect the structure of relocatable object files to identify the sections and symbols that the linker must resolve to create a final executable.
When you compile a C file, the compiler produces an object file (typically .o or .obj). This file is "relocatable" because it contains machine code, but it doesn't know where in the final system memory it will actually live. To manage this, the file is organized into distinct sections:
.text: Contains your actual executable instructions..data: Stores initialized global and static variables..bss: A placeholder for uninitialized variables..symtab(Symbol Table): An index mapping variable and function names to their relative offsets.
Consider this snippet:
int counter = 10;
void increment() {
counter++;
}
When compiled, the object file won't say "modify memory at 0x20000004." Instead, the .text section will contain an instruction like LDR R0, [PC, #offset] with a placeholder. The Symbol Table will record that counter is an entry located at a specific offset within the .data section.
Because the code is relocatable, these addresses are relative, not absolute. The linker’s job is to inspect these sections, read the symbol table, and calculate the final absolute memory addresses based on your target's memory map (e.g., placing .text in Flash and .data in RAM).
If you were to inspect an object file using a tool like objdump, you would see a "Relocation Table." This table acts as a to-do list for the linker, flagging every instruction that needs a "patch" once the final memory layout is determined. If the linker finds a symbol in the table that isn't defined anywhere, you get that classic "undefined reference" error during the final build phase.
By separating code into these categorized sections, the compiler ensures the linker has a clear map of what needs to be moved and what needs to be connected, allowing you to combine multiple source files into a single, functional embedded image.
Key Takeaway: Relocatable object files use sections and symbol tables to track relative addresses, leaving the final absolute memory resolution for the linking stage of the build process.