#296 host-built stage1: runtime-compiled code cannot call ANY baked defun (cold or warm) — unresolved trap spins to core
open
Opened by atgreen
Root class behind cave#293/#294's fragility. At the host-built stage1, a REPL- or stdlib-compiled call to any BAKED defun traps and spins into a core: (defun %q () (ag-norm-to-name "X"))(%q) crashes; warm fns too ((defun %r () (ag-pool-range-populated-p))(%r)); identical probes at stage2 work. ag-patches-apply's ag-runtime-fn-addrs fallback (stage1.lisp ~1040) claims to resolve static cold defuns by absolute fn-ptr — find why it doesn't cover host-built stage1 (table empty on host builds? warm fns excluded? patch never reached?). Consequences until fixed: stdlib code must never call baked defuns on paths reachable at stage1 (the cave#294 fix works around exactly this with a same-tier defvar gate); site stdlib.lisp:~2916 (UNDEFINED-DESIGNATOR) is the same latent class. Fixing this properly would let stdlib use the cave#244 fn-table-probe pattern everywhere without tier gymnastics.
Related datum from today's queue: cave#294's fix class (stdlib must not call baked defuns at stage1) held up across items #298/#300 — and cave#295's crash sits in the INVERSE direction (baked warm code funcall-by-name into runtime state at stage1), suggesting the stage1 dispatch/table degeneracy is bidirectional. The concrete investigation lead stands: ag-patches-apply's ag-runtime-fn-addrs fallback (stage1.lisp ~1040) — determine whether the host (elisp-emitted) build populates ag-runtime-fn-addrs at all; if it's empty there, REPL/stdlib-compiled calls to baked fns have no resolution channel and route to the trap, which matches every observed symptom. If populating it at host-emit time is feasible (the elisp host knows every fn+offset), that one change likely cures this whole class (#294's workaround, #295, and stdlib.lisp:~2916's UNDEFINED-DESIGNATOR latency).