CS 452/652 Winter 2026 - Lecture 4

Optimization and Debugging

Jan 15, 2026 prev next

Linking and Loading

• BSS section - "Block Started by Symbol"
  • linker script defines global symbols for start and end of section
  • C/C++ code declares these as external variables
  • use addresses to initialize BSS section
• C++ constructors: .init_array section
  • define start and end in linker script
  • treat as a array of function pointers in C++ code
  • loop and execute during program start

Memory Management

• techniques for dynamic data structures without heap
  • intrusive linkage, i.e., embed next (and/or other) pointers in data strucure
  • slab allocation: dedicated memory region (array of objects) for each data type
    • store freed objects in free list, use intrusive overlay (cast/union) to manage
    • allocate first from free list, then from slab
  • can use C++ templates (and inheritance) for elegant implementation

Compiler Optimization

• goal is complete understanding of what we are doing → enable optimization!
  • loop unrolling
  • code without side effects might be removed
  • register caching; repeated reads or writes might be removed
  • code reordering based on performance of microarchitecture
  • compiler understands data dependencies in sequential control flow
• C/C++ keyword "volatile"
  • tells compiler about unspecified side effects related to a variable or memory location
  • compiler avoids reordering around and removal of volatile accesses
  • example: memory-mapped device register

    int cloaddr = 0xFE000000 + 0x3000 + 0x04;
    volatile unsigned int* cloptr = (volatile unsigned int*)(cloaddr);
    unsigned int tval = *cloptr;
    

Runtime/Hardware Optimization

• pipelining and out-of-order execution, subject to data dependencies
• very important challenge in other areas!
  • basic mechanism: memory fence instructions (akin to flush)
• not too relevant for CS 452/652
  • using only one processor core
  • user/kernel don't share memory
  • exception handling: hardware cleans up processor pipeline

Concurrency

• manage independent activities or concerns
• conceptual reasons: software structure, runtime management
• practical reasons: parallel hardware
• asynchronous (unordered) execution, non-determinism
  → realtime: priority & preemption

Debugging

• often ad-hoc activity - reflect on it...
  • fundamentally:
    • software: model ↔ implementation
    • debugging: reconcile model and implementation
    • (your) program vs. environment (soft- and hardware)
  • what's in a bug?
    • error in model?
    • incorrect implementation?

      	Model	Implementation
      Program	Design	Coding
      Environment	Interface	Internals

  • potential problems
    • design: your model is incorrect
    • coding: your implementation does not realize your model
    • interface: your understanding of the environment is incorrect
    • internals: there is an unknown bug in the environment (unlikely)
  • debugging helps with verifying assumptions
  • basic technique: inspect and compare → alert
  • debugging strategy?
    • confirm or reject assumption
    • start with most (or least) likely assumption?
    • or start with most easy to confirm or reject?
• Experiments
  • testing & debugging fundamentally uses scientific methodology
    • build model → gather data → compare → repeat
  • no amount of experimentation can ever prove a model correct!
• Tools
  • tracing, logging (print)
  • checking (assert)
  • snapshot inspection
  • interactive debugging: breakpoints, single-stepping (if possible)
    • post-mortem (if reboot keeps RAM): need custom software
  • source or binary instrumentation
  • stack backtrace? see 'man backtrace' on Linux
    • not available in newlib, you could re-implement...
• Timing Challenges
  • real-time: timing critical for correctness
    • interactive debugging difficult
  • non-determinism: timing influences functionality
    • debugging changes timing behaviour: bug might disappear after changes
  • concurrency → non-determinism (race conditions)
    • software and real-world (trains)
• Race Condition (origin in circuit electronics)
  • (data) race: concurrent/parallel access to same resource
    • potential problem if one access is mutation
      → correctness problem, if one of the possible outcomes are wrong
      → ordering problem, repeatability
  • atomicity at bit level?
  • atomicity at word level? assignment vs. increment
  • race condition: problematic race requires coordination (synchronization)
    • coordination → performance vs. control
      • example: spin lock vs. mutex lock vs. fifo
      • lock-free coordination: typically spinning
    • non-determinism: matter of magnification/zoom/details?
      • actual sources of non-determinism: timer, keyboard, train
    • exact tracing in concurrent software too onerous
  • therefore we might see
    • high-level races: concurrent requests to resources (train, track)
    • non-repeatability: add/remove print statements?
    • asynchronous interrupts - should be no problem...