build_nistcurves_p256.sh: the #124 preflight diagnostic dies of its own bug, leaving a bare 'Error 128' #217

tools/integration/build_nistcurves_p256.sh:153 is the only one of three adjacent git calls without an || true guard:

151:  head="$(git -C "$LIB_DIR" rev-parse HEAD 2>/dev/null || true)"
152:  found="$(git -C "$LIB_DIR" describe --tags --always 2>/dev/null || echo '<unknown>')"
153:  pin="$(git -C "$PROJECT_ROOT" ls-tree HEAD libs/nistcurves 2>/dev/null | awk '{print $3}')"

The script runs under set -eo pipefail (:47). When PROJECT_ROOT is not a git repository, git ls-tree exits 128, pipefail carries that through awk, and set -e kills the shell mid-function — so the cat >&2 heredoc two lines below never runs.

Why that matters

Those lines are inside lib_preflight_fail, the #124 remedy block. The preflight at :194 correctly detects a missing libs/nistcurves/src/zp_config.s and calls it — and the diagnostic written specifically to explain that condition dies of its own bug before printing. What the caller sees instead is:

make: *** [build/lib/nistcurves-p256-onchip.a] Error 128

with no diagnostic at all.

Where it bites

tools/test_build_flags_stamp.py builds in a tempfile.mkdtemp "Farm" tree (:184). .git is not in FARM_LINKS (:95), so PROJECT_ROOT there is never a git repo. If the real libs/nistcurves is uninitialised, all 9 cases in that suite fail, plus the 4 in tools/test_flags_stamp_skip_is_loud.py (which re-runs the former in a subprocess) — 13 failures, all reporting Error 128 and nothing else.

That is exactly the context where the #124 message would be most useful, and it is the one context where it is unreachable.

Reproduction

Point a Farm-shaped temp tree at an uninitialised libs/nistcurves and run bash tools/integration/build_nistcurves_p256.sh onchip. bash -x shows the shell exiting at :153.

Fix

Add || true to :153, matching its two neighbours. No behaviour change on a healthy tree: there ls-tree exits 0 and the message prints with exit 1 as designed.

Not a regression

Verified against master 48657f5 and fix/uci-devicelock-timeout 032e22d in a properly-initialised worktree: 131 passed / 0 failed and 149 passed / 0 failed respectively, with test_build_flags_stamp.py alone green three times in a row (deterministic, not intermittent). The 13 failures are entirely explained by an uninitialised submodule plus this swallowed diagnostic.

Adjacent hazard, no action proposed

The Farm's LIB_DIR resolves through the libs symlink to the real checkout, and :306 runs make -s -C "$LIB_DIR", writing libs/nistcurves/build/. Two concurrent builds in one worktree share that directory. Not observed as a cause here, but a plausible second route to a confusing failure when several agents are active.