CMU Computer Systems: Linking

Static Linking

• Programs are translated and linked using a compiler driver
  • Source files
  • Separately compiled relocatable object files
  • Fully linked executable object file

Why linkers

• Modularity
  • Program can be written as a collection of smaller source files, rather than one monolithic mass
  • Can build libraries of common functions (more on this later)
    • e.g., Math library, standard C library
• Efficiency
  • Time: Separate compilation
    • Change one source file, compile, and then relink
    • No need to recompile other source files
  • Space: Libraries
    • Common functions can be aggregated into a single file
    • Yet executable files and running memory images contain only code for the functions they actually use

What linkers do

• Symbol resolution
  • Programs define and reference symbols (global variables and functions)
  • Symbol definitions are stored in object file (by assembler) in symbol table
    • Symbol table is an array of structs
    • Each entry includes name, size, and location of symbol
  • During symbol resolution step, the linker associates each symbols with exactly one symbol definition
• Relocation
  • Merges separate code and data sections into single sections
  • Relocates symbols from their relative locations in the .o files to their final absolute memory locations in the executable
  • Updates all references to these symbols to reflect their new positions

Three Kinds of Object Files (Modules)

• Relocatable object file (.o file)
  • Contains code and data in a form that can be combined with other relocatable object files to form executable object file
    • Each .o file is produced from exactly one source (.c) file
• Executable object file (a .out file)
  • Contains code and data in a form that can be copied directly into memory and then executed
• Shared object file (.so file)
  • Special type of relocatable object file that can be loaded into memory and linked dynamically, at either load time or run-time
  • Called Dynamic Link Libraries (DLLs) by Windows

Executable and Linkable Format (ELF)

• Standard binary format for object files
• One unified format for
  • Relocatable object files (.o)
  • Executable object files (a.out)
  • Shared object files (.so)
• Generic name: ELF binaries

ELF Object File Format

• Elf header
  • Word size, byte ordering, file type (.o, exec, .so), machine type, etc.
• Segment header table
  • Page size, virtual addresses memory segments (sections), segment sizes
• .text section
  • Code
• .rodata section
  • Read only data: jump tables, …
• .data section
  • Initialized global variables
• .bss section
  • Uninitialized global variables
  • “Block Started by Symbol”
  • “Better Save Space”
  • Has section header but occupies no space
• .symtab section
  • Symbol table
  • Procedure and static variable names
  • Section names and locations
• .rel .text section
  • Relocation info for .text section
  • Address of instructions that will need to be modified in the executable
  • Instructions for modifying
• .rel .data section
  • Relocation info for .data section
  • Addresses of pointer data that will need to be modified in the merged executable
• .debug section
  • Info for symbolic debugging (gcc -g)
• Section header table
  • Offsets and sized of each section

Linker Symbols

• Global symbols
  • Symbols defined by module m that can be referenced by other modules
  • E.g., non-static C functions and non-static global variables
• External symbols
  • Global symbols that are referenced by module m but defined by some other module
• Local symbols
  • Symbols that are defined and referenced exclusively by module m
  • E.g., C functions and global variables defined with the static attribute
  • Local linker symbols are not local program variables

Local Symbols

• Local non-static C variables vs. local static C variables
  • local non-static C variables: stored on the stack
  • local static C variables: stored in either .bss, or .data

How linker resolves duplicate symbol definitions

• Program symbols are either strong or weak
  • Strong: procedures and initialized globals
  • Weak: uninitialized globals

Linker’s Symbol Rules

• Multiple strong symbols are not allowed
  • Each item can be defined only once
  • Otherwise: Linker error
• Given a strong symbol and multiple weak symbols, choose the strong symbol
  • References to the weak symbol resolve to the strong symbol
• If there are multiple weak symbols, pick an arbitrary one
  • Can override this with gcc -fno-common

Global Variables

• Avoid if u can
• Otherwise
  • Use static
  • Initialize if you define a global variable
  • Use extern if you reference an external global variable

Packaging Commonly Used Functions

• How to package functions commonly used by programmers
  • Math, I/O, memory management, string manipulation, etc.
• Awkward, given linker framework so far
  • Put all functions into a single source file
  • Put each functions in a separate source file

Old-fashioned Solution: Static Libraries

• Static libraries (.a archive files)
  • Concatenate related relocatable object files into a single file with an index (called an archive)
  • Enhance linker so that it tries to resolve unresolved external references by looking for the symbols in one or more archives
  • If an archive member file resolves reference, link it into the executable
• Disadvantages
  • Duplication in the stored executables (every function needs libc)
  • Duplication in the running executables
  • Minor bug fixes of system libraries require each application to explicitly relink

Modern Solution: Shared Libraries

• Shared Libraries
  • Object files that contain code and data that are loaded and linked into an application dynamically, at either load-time or run-time
  • Also called: dynamic link libraries, DLLs, .so files
• Advantages
  • Dynamic linking can occur when executable is first loaded and run (load-time linking)
  • Dynamic linking can also occur after program has begun (run-time linking)
  • Shared library routines can be shared by multiple processes

Library Interpositioning

• Library insterpositioning: powerful linking technique that allows programmers to intercept calls to arbitrary functions
• Interpositioning can occur at
  • Compile time: when the source is compiled
  • Link time: when the relocatable object files are statically linked to form an executable object file
  • Load/run time: when an executable object file is loaded into memory, dynamically linked, and then executed

Some Interpositioning Applications

• Security
  • Confinement (sandboxing)
  • Behind the scenes encryption
• Debugging
  • Code in the SPDY networking stack was writing to the wrong location
  • Solved by intercepting calls to Posix write functions (write, writev, pwrite)
• Monitoring and Profiling
  • Count number of calls to functions
  • Characterize call sites and arguments to functions
  • Malloc tracing
    • Detecting memory leaks
    • Generating address traces