Relocatable object files

Example code

The ELF header begins with a 16-byte sequence that describes the word size, byte ordering of the system that generated the file
The locations and sizes of the various sections are described by the section header table.
Between are the sections themselves:
- .text: the machine code of the compiled program (assembly)
- rodata: read-only data such as the format strings in printf statements, and jump tables for switch statements
- .data: Initialized global and static C variables. Local C variables are maintained at run time on the stack and do not appear in either the .data or .bss sections.
- .bss (“better-save-space”): Uninitialized global and static C variables, along with any global or static variables that are initialized to zero. Object file formats distinguish between initialized and uninitialized variables for space efficiency: uninitialized variables do not have to occupy any actual disk space in the object file. At run time, these variables are allocated in memory with an initial value of zero
- symtab: A symbol table with information about functions and global variables that are defined and referenced in the program.
- .rel.text: a lif of location in the .text section that will need to be modified when the linker combines this object file with others. In general, any instruction that calls an external function or references a global variable will need to be modified
- .rel.data: relocation information for any global variables that are referenced or defined by the module. In general, any initialized global variable whose initial value is the address of a global variable or externally defined function will need to be modified.
- .debug: A debugging symbol table with entries for local variables and typedefs defined in the program, global variables defined and referenced in the program, and the original C source file. It is only present if the compiler driver is invoked with the -g option.
- .line: A mapping between line numbers in the original C source program and machine code instructions in the .text section. It is only present if the compiler driver is invoked with the -g option
- strtab: A string table for the symbol tables in the .symtab and .debug sections and for the section names in the section headers. A string table is a sequence of null-terminated character strings.
Additionally, there 3 pseudosections that don’t have entries in the section header table (they exist only in relocatable object files, not exist in executable object files)
- ABS: symbols that should not be relocated
- UNDEF: undefined symbols (symbols that are referenced in this module but defined elsewhere)
- COMMON: uninitialized data objects that are not yet allocated.
Difference between COMMON and .bss:
- COMMON: Uninitialized global variables
- .bss: Uninitialized static variables, and global or static variables that are initialized to zero.
- When a variable x is initialized to zero, it becomes a strong symbol (and then unique), the compiler can confidently assign it to .bss. Otherwise, there might exist other symbols with the same name in other modules, the compiler defers the decision to the linker by assigning x to COMMON.

Symbol and Symbol tables

A symbol typically refers to a name, label, or identifier used to represent a memory location, function, a global variable, static variable or any other entity within a program or across multiple programs/modules.
Each symbol is assigned to some section of the object file (ex: .data, .bss).
Symbol tables are built by assemblers, using symbols exported by the compiler into the assembly-language .s file. An ELF symbol table is contained in the .symtab section. It contains an array of entries
In the context of linker, there are 3 types of symbols:
- Global symbols: accessible across multiple modules (source files) without any special effort. They can be both defined and referenced within the same module, or defined in one module and referenced in another. (example: nonstatic C functions and global variables)
- External symbols: defined in 1 module (source file) but referenced in another module. They typically need to be resolved by the linker to connect the reference to the actual definition.
- Local symbols: defined and exclusively referenced only within a single module. (example: static C functions, static C global variables)
Each relocatable object module, m, has a symbol table that contains information about the symbols that are defined and referenced by m

The symbol table .symtab does not contain any symbols that correspond to local nonstatic program variables. They are managed at run time on the stack.
The format of each entry:
- name: a byte offset into the string table that points to the null-terminated string name of the symbol.
- value: the address of the symbol.
  - For relocatable modules, value = offset from the beginning of the section where the object is defined.
  - For executable object files (after the linking phase), value = absolute run-time address
Example:

Symbol .symtab entry ? Symbol type Module where defined Section
buf Yes external m.o .data
bufp0 Yes global swap.o .data
bufp1 Yes global swap.o COMMON
swap Yes global swap.o .text
temp No - - -
Example 2: local symbol
```
int f(){
    static int x = 0;
    return x;
}
int g(){
    static int x = 1;
    return x;
}
```
- Symbol x is local.
- The compiler exports a pair of local linker symbols with different names to the assembler. For example, it might use x.1 for the definition in function f and x.2 for the definition in function g.

Symbol	.symtab entry ?	Symbol type	Module where defined	Section
buf	Yes	external	m.o	.data
bufp0	Yes	global	swap.o	.data
bufp1	Yes	global	swap.o	COMMON
swap	Yes	global	swap.o	.text
temp	No	-	-	-