Component: hwjs-cc / HwjsCoroutinize, e8-registry phase
Found: 2026-07-15, coreutils 9.4, Yocto glibc arm (core-image-brintos-emcraft, MACHINE=brintos-wasm32, TCLIBC=glibc)
Toolchain: hwjs-cc d3aa993 (F163), superproject ecb8f63. Both d51b4e6 (the #16 classify memo) and 4278a49 (F162, the #1 e8-registry round memo) are ancestors of this HEAD — verified with git merge-base --is-ancestor.
Symptom. Linking coreutils src/factor (which links GMP's mpn code), the e8-registry escape walk never converges. Two runs, identical except the budget:
BUDGET REFUSE phase=e8-registry fn=hgcd_hook exceeded=wall-clock elapsed_ms=600016 budget_ms=600000 work_units=129056768 work_budget=0
BUDGET REFUSE phase=e8-registry fn=hgcd_hook exceeded=wall-clock elapsed_ms=7200062 budget_ms=7200000 work_units=1501134848 work_budget=0
12x the wall-clock bought 11.6x the work and no convergence — a flat ~210k units/s with no sign of a fixpoint. That is #1's "work-units unconverged, still climbing" signature, but on GMP's hgcd_hook rather than clang's visitExpr: F162's round-scoped memo bounds the clang SCC shape and does not bound GMP's recursive mpn web in this phase.
Why this is not the existing issues.
- linux-in-the-browser#16 (closed) was the classify-phase blowup;
d51b4e6fixed it and is present — classify is not where we spin. - hwjs-cc#1 (closed, F162) fixed e8-registry for the clang
visitExprshape. Its close note says: "If it still budget-refuses, post the attributed line and I'll take it from there." This is that line, for a different shape. - linux-in-the-browser#25 (closed) is the GMP
TMP_ALLOCescape refusal set — a fast, loud refuse, not a spin.
Repro. MACHINE=brintos-wasm32 TCLIBC=glibc bitbake coreutils with the emcraft tool set (no --enable-no-install-program); watch the src/factor link. Every other coreutils tool links in ~1s on the same host — the pass's own BUDGET-OK telemetry shows ~0.9-1.1s / ~0.4-0.5M units per function there.
On the ops knob. The refuse text recommends raising HWJS_CORO_BUDGET_SECONDS. For this shape that advice is a multi-hour dead end — we spent 2h of a shared build host to learn it buys nothing. It may be worth having the attributed refuse say so when work-units are climbing linearly, rather than pointing at a budget that cannot help.
Impact. Blocks core-image-brintos-emcraft (glibc): 1916 tasks, 924 from sstate, exactly one failure — this link. The --enable-no-install-program=expr,factor workaround sanctioned in #16/#25 remains the way out and is what we will carry.
No candidate fix. The defect is in the pass's escape-walk memoization, upstream in hwjs-cc; we have no diagnosis of the pass internals to offer and therefore no branch and no patch — reporting evidence only.