CS 452/652 Winter 2020 - Lecture 16

February 10, 2020 prev next

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?

	Model	Implementation
Own	Design	Coding
Environment	Interface	Internals

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

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>

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!

"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)

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!!