CS 452/652 Fall 2019 - Lecture 18

Debugging

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

• 	Model	Implementation
  Own	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 design/interface
  • verifying coding/internals
• basic technique: inspect and compare → alert
• debugging strategy
  • rule out or confirm problems
  • start with most likely problem?
  • or start with most easy to rule out?

Experiments

• debugging fundamentally uses scientific methodology
  • build model → gather data → compare
  • repeat
• no amount of experimentation can ever prove a model correct!

Tools

• logging (print)
• checking (assert)
• snapshot inspection
  • interactive debugging: breakpoints, single-stepping
  • post-mortem (reset keeps most RAM): gdb or custom software
  • source or binary instrumentation
• stack backtrace? see 'man backtrace' on Linux
  • not available in newlib, you could re-implement...
• execution trace: str pc, <location>

Real-Time

• new correctness criterion: timing
• "benign" program changes (such as print) change timing behaviour
• concurrency and races → non-determinism
• non-determinism → bug might appear/disappear after "benign" changes
• real-time → interactive debugging difficult
  • program suspended, but real world (trains) keeps moving!

Gdb

Operation

• "regular" hosted environment (such as Linux)
  • hardware: special instruction, exception
  • operating system
    • start/stop/attach thread
    • write to code segment of process
  • breakpoint - write special instruction, handle exception
  • continue - rewrite original code, resume execution
  • single step - breakpoint at next instruction (or source code line)
  • example: see 'man ptrace' on Linux
• otherwise: remote operation
  • gdb stub/server co-located with target
  • EP 9302: gdb stub in RedBoot
  • communication over serial link or network (TCP)

ARM

• breakpoint implemented as 'undefined instruction' (udf)
• udf handler accessed via branch in 0x04, destination in 0x24
  • udf handler invokes gdb stub
  • make sure 0x04/0x24 are not modified from reset defaults!
• works for breakpoints/single-stepping kernel code (in SVC mode)
• debug operation: run user tasks in System mode
  ⇒ breakpoints/single-stepping should work for most code
• however, assignment submissions must run user tasks in User mode!!

Other

• EP 9302 reset does not wipe all RAM (only RedBoot memory) → use for post-mortem
• gdb's 'disassemble' command disassembles arbitrary memory regions when using two arguments: start and (end or size)
• online disassembler at https://onlinedisassembler.com/odaweb/