Building, Testing, and Debugging
Programming Environment
COP-3402

How do you build a C program?

gcc -o hello hello.c

What if I have two C files?

gcc -o main main.c hello.c

What if I have 30,000+ C files?

gcc -o vmlinux kernel/locking/mutex-debug.c \
  kernel/locking/rwsem.c kernel/locking/rtmutex.c \
  kernel/locking/qrwlock.c kernel/locking/irqflag-debug.c \
  kernel/locking/test-ww_mutex.c kernel/locking/mutex.c \
  # 30,000+ more

Why not build the whole program at once?

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
find kernel/ arch/ block/ crypto/ drivers/ fs/ init/ ipc/ lib/ mm net/ security/ sound/ virt/ -name "*.c" | wc -l

• Long compilation time
• Small changes require complete recompile

main.c

#include <stdio.h>

int square(int);

int main() {
  printf("%d\n", square(3));
}

square.c

int exponent(int x, int y);

int square(int x) {
  return exponent(x, 2);
}

exponent.c

int exponent(int x, int y) {
  int result = 1;
  for (; y > 0; result *= x, y--);
  return result;
}

How do we separately compile this program?

gcc -c main.c

-c compiles the .c file to an object file .o

Compile each .c file (without linking) to a .o object file

gcc -c main.c  # -c flag produces .o files
gcc -c square.c
gcc -c exponent.c

Then link all object files into a single program binary

gcc -o main main.o square.o exponent.o  # pass .o files

Only rebuild source files that changed.

emacs main.c   # modify one source file
gcc -c main.c  # recompile it

Re-link with existing object files

gcc -o main main.o square.o exponent.o

target … : prerequisites …
        recipe
        …
        …

main:
        gcc -o main main.c square.c exponent.c

main:
        gcc -o main main.c square.c exponent.c

clean:
        rm -f main

main: main.c square.c exponent.c
        gcc -o main main.c square.c exponent.c

main: main.o square.o exponent.o
        gcc -o main main.o square.o exponent.o

main.o: main.c
        gcc -c main.c

square.o: square.c
        gcc -c square.c

exponent.o: exponent.c
        gcc -c exponent.c

make
touch main.c
make

main: main.o square.o exponent.o
        gcc -o main main.o square.o exponent.o

%.o: %.c
        gcc -c $<

PROG := main
SRC = main.c square.c exponent.c
OBJ = $(SRC:%.c=%.o)

$(PROG): $(OBJ)
        $(CC) $(CFLAGS) -o $@ $^

%.o: %.c
        $(CC) $(CFLAGS) -c -o $@ $<

PROG := main
SRC = main.c square.c exponent.c
OBJ = $(SRC:%.c=%.o)

.PHONY: all clean

all: $(PROG)

$(PROG): $(OBJ)
        $(CC) $(CFLAGS) -o $@ $^

%.o: %.c
        $(CC) $(CFLAGS) -c $<

clean:
        $(RM) $(PROG) $(OBJ)

• Run tests
• Generate documentation
• Anything you can script in bash

• The program does something wrong

• A program that does what it's supposed to do, but not what we think it does

1. Narrow down the problem by crafting a smaller version of the test case
2. Go to the part of the your code that is related to the problem
3. Trace step-by-step what your code really does (not what you think/hope/feel/guess/divine/intuit/reckon it does)

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" –Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2.

• Easier to get the implementation right
• Gradually expand the specification
• Keep the implementation correct at each step

• Can't keep all code in mind for all time
• Make it easier for yourself
• Delay gratification
  • Finishing code fast feels good
  • Debugging shoddy code feels horrible

(Diagram)

• Breaking problems down takes time, experience, and making mistakes
• Premature generalization can waste work
• Don't be afraid to refactor
  • Easier to reorganize code after prototyping than to write from scratch (for large programs)

• Hides unnecessary details, exposes clear, simple interfaces
• Physical examples: cars, locks, sockets
• Interface decisions determined by use of that abstraction

• One of the most common and powerful
• Names a snippet of code
• Provides a definition of input and output
  • Developer provides documentation of behavior and usage
• You'll get to implement support for functions in your compiler

• Abstractions create software components
• Components can be tested on their own
• Developer can forget about details of the component
  • As long as the component is thoroughly tested and documented
• Large systems are composed of many layers of abstraction

• Bugs are (usually) not wrong programs, but incorrect assumptions
• Break the problem down into simpler specifications
• Use abstractions to build larger programs

• Program Development by Stepwise Refinement
• One methodology for breaking down a problem into abstractions