make p384-overlay fails to link (unresolved ec_base384_x/y)

[JC-000]

make p384-overlay fails with unresolved ec_base384_x/ec_base384_y

Summary

make p384-overlay — the Phase C.3b target that builds build/lib/overlay-p384.bin + build/labels-p384.txt for use by tools/test_p384_symbols.py — fails to link with unresolved references to ec_base384_x and ec_base384_y from libs/nistcurves/src/points384_raw.s (or whichever P-384 source pulls in the Lim-Lee fixed-base-G anchor table).

This is a pre-existing bug, not introduced by any Phase C commit. Reproduces on 78f0918 (the squashed PR #31 merge) and reproduces on the pre-PR-#31 tip as well. It's been surfaced by Phase C.3b's standalone-overlay build cfg — the in-tree c64-https build doesn't link P-384 into the production PRG, so it only manifests when you explicitly make p384-overlay for the smoke test.

Repro

cd /home/someone/c64-https
make p384-overlay

Expected: two artifacts — build/lib/overlay-p384.bin (8 KB) and build/labels-p384.txt (label table). Allows tools/test_p384_symbols.py to upload the P-384 image into REU via the harness and exercise ec_point_double_384 / ec_point_add_384 / ec_jacobian_to_affine_384 against NIST vectors.

Observed: ld65 error — Unresolved external ec_base384_x (and ec_base384_y).

Why

The sibling c64-nist-curves repo exports these anchor labels from its own data.s / main.s for the Lim-Lee fixed-base-G comb used by ec_scalar_mul_384. The Phase C.3b build/lib/nistcurves-p384.a archive deliberately EXCLUDES ec_scalar_mul_384 and ec_precompute_384 (they're fixed-base-only and unused by the smoke test), so the anchors should drop out of the link. But points384_raw.s (or the P-384 data file) still references them at module scope, keeping the undefined reference alive.

Scope

This is orthogonal to the currently-shipped Phase C.4 ECDSA-P-256 integration. That integration does NOT need P-384 primitives linked and does not exercise p384-overlay. Closing this bug is a prerequisite for TLS-level P-384 enablement (ecdsa_verify_384 is still stubbed in TLS per project_p384_stubbed).

Fix paths

Pick one:

1. Narrow the P-384 archive further in tools/integration/build_nistcurves_p384_bin.sh. Strip whatever symbol scope still references ec_base384_x/y. Likely a module-level .import in points384_raw.s or similar — wrap in an .ifdef gate or exclude that file entirely if its only caller is ec_scalar_mul_384.

2. Stub ec_base384_x/y as empty labels in our local build. Safe because the smoke test never reaches any code path that dereferences them. One-line .import → .export alias file would do it.

3. Upstream a variant archive target at JC-000/c64-nist-curves that packages only the variable-base P-384 primitives without the Lim-Lee anchors. Cleanest but highest coordination cost.

Acceptance

• make p384-overlay succeeds.
• python3 tools/test_p384_symbols.py runs without the "labels-p384.txt missing" skip and exercises P-384 primitives against NIST FIPS 186-4 vectors successfully.

Relevant files

• tools/integration/build_nistcurves_p384_bin.sh — the build wrapper
• libs/nistcurves/src/points384_raw.s — likely culprit for the unresolved reference
• libs/nistcurves/src/data.s — where ec_base384_x/y are defined
• tools/test_p384_symbols.py — downstream consumer that's currently bypassed
• CLAUDE.md — known-issues entry under "Phase G end state"

[JC-000]

Closing as obsolete-as-written — the diagnosis and fix paths in this issue no longer match reality at master @ 6373036 (2026-07-26, libs/nistcurves @ v0.6.0):

make p384-overlay now fails earlier than the ec_base384_x/y link error described here — the sibling build wrapper (tools/integration/build_nistcurves_p384.sh) dies at the ar65 archive step because the upstream staging layout drifted under the v0.5.0/v0.6.0 bumps (nistcurves_p384_staging/curve/ecdsa384.o is never produced). The unresolved-external analysis, the three proposed fix paths, and the file references in this writeup are all stale against the v0.6.0 tree.

The P-384 overlay target has still never built cleanly, and TLS-level P-384 remains stubbed — that state is documented in CLAUDE.md ("Known issues" + the P-384 wall-clock section). If/when P-384 enablement resumes, a fresh issue should be filed against the current failure mode rather than resurrecting this one.