Build Systems & Toolchain

Question 1 (12 marks)

(a) [5]

• The linker processes inputs left to right, maintaining a set of unresolved symbols. (1)
• When it encounters an archive (.a), it only pulls in member object files that resolve a currently unresolved symbol. (1)
• In gcc libutil.a app.o: at the time libutil.a is scanned, no symbol is yet unresolved (app.o not seen yet), so util.o is not extracted; then app.o references helper, but the archive is already past → undefined reference. (2)
• In gcc app.o libutil.a: app.o is processed first, leaving helper unresolved; then libutil.a is scanned and util.o is pulled in to satisfy it → success. (1)

(b) [3]

• Use grouping: gcc app.o -Wl,--start-group -lutil -lmath -Wl,--end-group -o prog (2)
• The linker option is --start-group/--end-group (-( / -)), which repeatedly rescans the enclosed archives until no new symbols are resolved. (1)

(c) [4]

• For static archives, order matters because members are extracted only on demand as unresolved symbols exist. (1)
• For shared objects, the entire library's symbol table is made available; the dynamic symbols are recorded and resolved as a whole, so a .so can satisfy references from objects placed before or after it on the command line in typical configurations. (2)
• Reason: with --as-needed behaviour a .so may still need to appear before use to be recorded, but fundamentally an archive is a collection of separable .o files pulled selectively, whereas a .so is a single indivisible unit with a complete symbol table. (1)

Question 2 (14 marks)

(a) [9] Example acceptable Makefile:

CC      := gcc
CFLAGS  := -Iinclude -Wall
SRC     := $(wildcard src/*.c)
OBJ     := $(patsubst src/%.c,build/%.o,$(SRC))
 
bin/calc: $(OBJ)
	@mkdir -p bin
	$(CC) $^ -o $@
 
build/%.o: src/%.c
	@mkdir -p build
	$(CC) $(CFLAGS) -c $< -o $@
 
.PHONY: clean
clean:
	rm -rf build/* bin/*

Mark scheme:

• OBJ derived from source list via patsubst/wildcard — 2
• Pattern rule build/%.o: src/%.c with -c compile — 2
• Correct link rule producing bin/calc from $(OBJ) — 2
• Use of automatic variables $<, $@, $^ correctly — 1
• .PHONY: clean with a removal recipe — 2

(b) [3]

• $< → the first prerequisite (here src/%.c, the single source file). (1)
• $@ → the target name (e.g. build/parse.o or bin/calc). (1)
• $^ → all prerequisites, space-separated, duplicates removed (the full object list in the link rule). (1)

(c) [2]

• Generate dependency files with the compiler and include them, e.g. add -MMD -MP to CFLAGS and -include $(OBJ:.o=.d) in the Makefile (auto-generated .d files list header dependencies). (2) (Also acceptable: manually listing headers as prerequisites.)

Question 3 (12 marks)

(a) [6] — 2 marks each:

• Line 4 (a[4]=7 on a 4-element malloc): ASan — heap buffer overflow (out-of-bounds write). (2)
• Line 5 (1 << 31 on int): UBSan — signed integer overflow / left-shift into sign bit (undefined behaviour). (2)
• Line 7 (return a[0] after free(a)): ASan — heap-use-after-free. (2) (TSan reports data races; none of these are data races.)

(b) [3]

• Compile with -fsanitize=address,undefined -g (both in one -fsanitize list). (2)
• ASan and TSan cannot coexist because both instrument memory access with incompatible, conflicting runtime memory layouts / shadow-memory schemes; they are mutually exclusive in one binary. (1)

(c) [3]

• Use a watchpoint — GDB stops when a memory location's value changes. (1)
• Command: watch a[0] (a data/hardware watchpoint), then run/continue. (2)

Question 4 (12 marks)

(a) [6] Example:

cmake_minimum_required(VERSION 3.10)
project(demo_project C)
 
add_library(mathx STATIC mathx.c)
add_executable(demo main.c)
target_link_libraries(demo PRIVATE mathx)

Mark scheme:

• cmake_minimum_required + project — 2
• add_library(mathx STATIC mathx.c) — 2
• add_executable(demo main.c) + target_link_libraries(demo ... mathx) — 2

(b) [3]

• Debug: no/low optimization + debug info, roughly -g -O0 (defines nothing special). (1)
• Release: high optimization, no debug info, defines NDEBUG — roughly -O3 -DNDEBUG. (1)
• Configure RelWithDebInfo: cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo .. (yields -O2 -g -DNDEBUG). (1)

(c) [3]

• CMAKE_SYSTEM_NAME (target system, e.g. Linux) and CMAKE_SYSTEM_PROCESSOR (e.g. aarch64); plus CMAKE_C_COMPILER set to the cross-compiler (e.g. aarch64-linux-gnu-gcc). Accept naming the compiler variable + system name variable. (2)
• The sysroot (CMAKE_SYSROOT) provides the target's headers and libraries so the cross-compiler links against target-appropriate (not host) system libraries. (1)

Question 5 (10 marks)

(a) [3]

• objdump -d -S hot.o (or objdump --disassemble --source hot.o); -S interleaves source with assembly. (3) (requires -g at compile for source interleaving.)

(b) [4] Amdahl's law:

• Fraction sped up $p = 0.8$, speedup factor $s = 4$. (1)
• Overall speedup $= \dfrac{1}{(1-p) + p/s} = \dfrac{1}{0.2 + 0.8/4} = \dfrac{1}{0.2 + 0.2} = \dfrac{1}{0.4}$. (2)
• $= 2.5\times$. (1)

(c) [3]

• gprof: sampling-based statistical profiler + call-graph via instrumentation (-pg); low overhead but approximate/statistical timing. (1.5)
• valgrind --tool=callgrind: exact instruction/call counts via full binary instrumentation; very accurate counts but large slowdown (10–50×) and simulated, not wall-clock, timing. (1.5)

[
  {"claim":"Amdahl overall speedup with p=0.8, s=4 is 2.5", "code":"p=Rational(8,10); s=4; result = (1/((1-p)+p/s) == Rational(5,2))"},
  {"claim":"Denominator (1-p)+p/s equals 0.4", "code":"p=Rational(8,10); s=4; result = ((1-p)+p/s == Rational(2,5))"},
  {"claim":"1<<31 exceeds max signed 32-bit int (2**31-1)", "code":"result = ((1<<31) > (2**31 - 1))"},
  {"claim":"malloc(4*sizeof int) valid indices are 0..3 so index 4 is out of bounds", "code":"n=4; result = (4 >= n)"}
]