The Makefile comment that compiled out all logging

Adam Szefer · Co-founder & CTO

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

One of our design partners' boards booted in simulation and printed nothing. The UART model was fine and the firmware was fine. The bug was a comment in the Makefile, and it had been silencing every default build on real hardware too.

The symptom

The firmware ran, its peripherals were set up, and the console stayed empty. On the bench the team had got used to building with extra flags to get logs, so nobody had connected the silence to the build. In simulation there is no habit to hide behind: a default build printed nothing, every time.

The line

The Makefile set a default debug level and checked it later. It looks correct, and it is the kind of line that passes review.

Simplified from the partner's Makefile
DEBUG ?= 1    # set to 0 for release builds

ifeq ($(DEBUG),1)
  CFLAGS += -DDEBUG_LEVEL=DEBUG_LEVEL_INFO
else
  CFLAGS += -DDEBUG_LEVEL=DEBUG_LEVEL_NONE
endif

Why it never matched

GNU make strips leading whitespace from a variable's value but keeps trailing whitespace, and a comment ends the value only after those spaces. So DEBUG is "1 ", not "1". The ifeq compares the two strings exactly, takes the else branch, and every default build is compiled with logging off. Passing DEBUG=1 on the command line works, because there is no comment there, which is why it went unnoticed.

The fix

Put the comment on its own line, or strip the value where it is used: ifeq ($(strip $(DEBUG)),1). Either change is one line. A quick check for the rest of a codebase: grep for ?=, := or = followed by spaces and a # on the same line.

Why simulation found it

A simulated board runs exactly the build you give it, from reset, with a console that is always connected. When nothing comes out, the question becomes what the firmware did rather than whether the cable is plugged in. Reading the build flags the firmware was compiled with took minutes; on the bench the same silence had been worked around for months.

HardLabs

Send us your design. We'll send you a simulator.

We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.

  • A working simulator of your board, built from netlist, schematic, and BOM.
  • Peripheral models attached so your firmware can talk to the board.
  • A setup that runs your real firmware binary — no rewrite required.

Pilot details · App

Related

HardLabsAll blog