linker related

To build the executable, the linker must perform two main tasks:

Symbol resolution. Object files define and reference symbols. The purpose of symbol resolution is to
associate each symbol reference with exactly one symbol definition.
Relocation. Compilers and assemblers generate code and data sections that start at address zero. The
linker relocates these sections by associating a memory location with each symbol definition, and
then modifying all of the references to those symbols so that they point to this memory location.

Object files come in three forms:
Relocatable object file. Contains binary code and data in a form that can be combined with other
relocatable object files at compile time to create an executable object file.
Executable object file. Contains binary code and data in a form that can be copied directly into
memory and executed.
Shared object file. A special type of relocatable object file that can be loaded into memory and linked
dynamically, at either load time or run time.

ELF relocatable object file contains the following sections:
.text: The machine code of the compiled program.
.rodata: Read-only data such as the format strings in printf statements, and jump tables for switch
statements (see Problem 7.14).
.data: Initialized global 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: Uninitialized global C variables. This section occupies no actual space in the object file; it is merely
a place holder. 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.
.symtab: A symbol table with information about functions and global variables that are defined and
referenced in the program. Some programmers mistakenly believe that a program must be compiled
with the -g option to get symbol table information. In fact, every relocatable object file has a symbol
table in .symtab. However, unlike the symbol table inside a compiler, the .symtab symbol table
does not contain entries for local variables.
.rel.text: A list of locations 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. On the other hand, instructions that call local
functions do not need to be modified. Note that relocation information is not needed in executable
object files, and is usually omitted unless the user explicitly instructs the linker to include it.
.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.
Aside: Why is uninitialized data called .bss?
The use of the term .bss to denote uninitialized data is universal. It was originally an acronym for the “Block
Storage Start” instruction from the IBM 704 assembly language (circa 1957) and the acronym has stuck. A simple
way to remember the difference between the .data and .bss sections is to think of “bss” as an abbreviation for
“Better Save Space!”. End Aside.