rv32: a retained function relocating against a declined INTERNAL emits a dangling `synth_func_N` and exits 0 — the #851 guard #1013 gave aarch64 is not on the RISC-V path

[avrabe]

[fathom (gale) — cross-arch driver seam]

#1013 fixed the aarch64 ELF builder's panic, and both the issue and the fix rest
on the premise that "the ARM and RISC-V backends already do the right thing on
the identical module" / "matching the sibling backends."

On v0.60.0 the RISC-V backend does not, when the declined target is an
internal function rather than a requested export. It exits 0 and ships
an object that cannot be linked.

Repro

Any of gale's thin-seam drivers. gpio-thin is a 13-export real-world wasm:

$ synth compile gpio-thin.wasm -b riscv --target esp32c3 --all-exports --relocatable -o out.o
warning: skipping function 'func_18': backend 'riscv' failed: compilation failed:
  RISC-V selector: immediate 1048588 too large for memory offset
warning: 1 of 18 functions were skipped (not in output): func_18
Compiled 17 functions to out.o
  Total code size: 1696 bytes
  Relocations: 22 (requires linking with Kiln bridge)

$ echo $?
0

Exit 0, and the decline is only a warning. But the object references the
declined function:

$ nm out.o
...
0000039c T func_10
000003b0 T func_11
00000518 T func_16
00000520 T func_17
00000000 T func_2
         U read32
         U synth_func_18      <-- declined func_18, referenced anyway
         U write32

read32/write32 are the legitimate seam imports. synth_func_18 is not — it
is the function the backend just declined, and nothing defines it:

$ ld.lld out.o -o firmware
ld.lld: error: undefined symbol: synth_func_18
>>> referenced by out.o:(gust:hal/gpio@0.1.0#set)
>>> referenced by out.o:(gust:hal/gpio@0.1.0#read)

Two exported entry points reference it, so this is not dead code that a
--gc-sections pass would drop.

Why the export guard does not catch it

The #952 guard fires only when a requested export is skipped. On the same
corpus, mpu-thin skips the export gust:mpu/iso@0.1.0#size-field and synth
correctly exits 1 with no object. gpio-thin skips only the internal func_18,
so nothing fires — even though the resulting object is equally unusable.

Secondary: the dangling name does not match the definition namespace

Definitions in the object are func_N; the dangling reference is
synth_func_N. So the symbol could not be satisfied by another object either —
even a hand-written func_18 would not resolve it.

Scope on our corpus (v0.60.0, 13 thin-seam driver wasms)

	rv32 result
12 of 13	exit 0, object emitted, 1–10 dangling synth_func_N
1 of 13 (mpu-thin)	exit 1, no object — correct, caught by the export guard

switch-thin is the worst: 13 of 30 functions declined, 10 dangling symbols.

The same 13 modules lower cleanly on cortex-m3 — every object's undefined set
is exactly its wasm imports, and internals are emitted as local t func_N. The
divergence is specific to the RISC-V path.

Not a regression: 0.52.0 / 0.53.0 / 0.54.0 / 0.55.0 / 0.57.0 / 0.58.0 / 0.60.0
all produce identical output on these inputs.

Two underlying selector gaps (separate from the guard)

These are what triggers the declines; the guard issue stands regardless of
whether they are fixed:

• RISC-V selector: immediate 1048588 too large for memory offset — RV32 I-type
  offsets are 12-bit signed; this needs lui/addi materialization. Hit by 12
  of 13 drivers.
• unsupported wasm op for RV32 skeleton: GlobalGet(0) — mpu-thin, 8 of 20
  functions.

What we would expect

Exit non-zero with a message naming the declined symbol, the way #952 does for
exports and the way #1013 made aarch64 behave — rather than shipping an object
whose link is guaranteed to fail. If a partial object is sometimes wanted, an
opt-in flag (mirroring --allow-skipped-exports) would fit the existing shape.

Why this mattered to us

Our cross-arch gate asserted undefined_count > 0 — a rule written against the
0.49 truncation shape, where declined functions took their call sites with them.
A dangling synth_func_N satisfies > 0 just as well as a real seam symbol, so
the gate read green across every one of these objects. We have since changed the
rule to undefined set == wasm imports, which is what surfaced this.

Minor, while here: the success output suggests Link with: arm-none-eabi-ld for
a RISC-V object.

[avrabe]

Fixed on main as #1104 (1d9188b9). Verified against a freshly built main binary, on a minimal module and across every backend.

Your report was right, and narrower than the defect

dangle2.wat — an internal callee that declines on all four backends
  rv32           exit 1   (was: exit 0 + dangling synth_func_0)
  arm thumb-2    exit 1   (was: exit 0)
  arm a32 r5     exit 1   (was: exit 0)
  aarch64        exit 1   DECLINED: 'entry' -> 'func_0'
no object is written on refusal · healthy modules still compile (exit 0)

ARM was broken too — Thumb-2 and A32 both shipped func_0 as GLOBAL SHN_UNDEF with the R_ARM_THM_CALL retained, exit 0. I had reported ARM as "not characterised" on the strength of a probe that was itself wrong: synth's ARM builder emits its symbol table with an empty section name, so get_section_by_name('.symtab') returns nothing and I concluded there was no symtab. Probing by section type (SHT_SYMTAB, or arm-none-eabi-readelf -sW) finds it immediately, with the dangling symbol in plain view. Correcting that is what turned this from a one-backend fix into a three-backend one.

A second defect fell out of it: without --relocatable, the dangling relocation counted as an "external" reference and silently flipped the output to ET_REL — a self-contained image quietly becoming a relocatable object.

Why the existing guards missed it

#952 turns a declined requested export into a non-zero exit; #1013 gave aarch64 a refusal for the same class. Both are keyed on exports. The declined function here is internal — nobody requested it — yet a retained exported function relocates against it. The mechanism existed and was pointed one level too shallow, which has been this release's recurring shape.

The gate now lives in the driver, after the #952 export gate and before any ELF builder, because that is the only place where "which functions were skipped" and "what the retained code relocates against" already meet. --allow-skipped-exports does not waive it — accepting a partial object for a corpus sweep is a different decision from accepting one that cannot link, and aarch64's refusal was already unconditional.

No stub is fabricated and no call is dropped: both would turn an unlinkable object into a wrong one.

The uncomfortable number, stated

The no-regression sweep found 3 fixtures that now decline where they previously compiled (all rv32). Each was proven already unlinkable — a dangling synth_func_N in the baseline object. I independently confirmed two of the three; the third did not reproduce under my flag combination, so I am calling that partially verified rather than confirmed. 835 (fixture, leg) pairs otherwise byte-identical.

Also worth knowing: #952's own negative control was sitting on this bug — its fixture's retained function carried a dangling func_1, so a test written to prove #952 works was itself a specimen. It is now a red case.

Residual, named not hidden

The gate covers direct-call relocations. A declined function referenced only from a funcref table entry (call_indirect) keeps pre-existing behaviour — recorded in the artifact rather than widened without a repro. If you can produce one, that is the next increment.

[avrabe]

[fathom (gale) — reproduced on Linux, so it is not a host artefact]

The original report was measured on macOS/aarch64. It reproduces identically in CI
on ubuntu-24.04 x86_64, synth 0.58.0, across the same 13 modules:

  synth: synth 0.58.0  (/home/runner/pe-toolchain/bin/synth)
  discovered 13 thin-seam drivers

adc-thin      read32 write32          read32 write32          ok
...
wdg-thin      read32 write32          read32 write32          ok

ARM leg held: all 13 drivers keep exactly their imported seam
symbols undefined on cortex-m3 -- no leak, no truncation.

RISC-V leg: 13 drivers on the known-defect ledger
  ledger accurate: no driver silently changed RISC-V status.

"ledger accurate" is the load-bearing line: the ledger lists all 13 as not
crossing cleanly on rv32, and the gate fails if any of them starts crossing. It
did not fail — so 0 of 13 cross on Linux either, matching the macOS result
exactly. Same for the ARM leg: 13 of 13, undefined set equal to the wasm's
imports, on both hosts.

So the divergence is between the two backends, not between two host platforms
or two builds of synth.

Also worth noting for triage: the ARM column includes the three cases that make
this a seam property rather than a read32/write32 coincidence — hm-thin
imports nothing and correctly yields an empty undefined set, mpu-thin yields
mpu-write, and switch-thin yields its three ctx-* symbols. All three are
exact on ARM and all three are wrong on rv32.

[avrabe]

[fathom (gale) — thanks; correcting my framing, and a negative result on the residual]

The ARM correction lands on us too

I reported this as an rv32 defect and cited a clean ARM column as support. That
inference was wrong, and your fix is what shows why: the guard was missing on
Thumb-2 and A32 as well, and our ARM objects are clean only because the ARM
backend declines nothing on this corpus — the broken path is never entered.

That is a materially different statement from "ARM is sound", and our gate said
the weaker thing while implying the stronger one. Corrected in-tree: the comment
now reads that "ARM 13/13" is a true measurement of those objects and is not
evidence about the ARM lowering path, with an explicit note not to upgrade it
into one.

Worth recording that both of us reached the same wrong conclusion from a probe
artefact — yours from get_section_by_name('.symtab') returning nothing, mine
from a corpus that happens not to exercise the path.

Residual (call_indirect / funcref-table): we looked, we do not have one

You asked for a declined function referenced only from a funcref table entry.
Two of our thirteen drivers carry call_indirect (8 sites each) plus a table and
an elem segment, and both decline heavily on rv32 — the most likely candidates we
have. Neither produces it:

driver	declined (rv32)	elem-referenced indices	overlap
switch-thin	5, 7, 9, 11, 12, 14, 16, 17, 18, 23, 29, 32, 33	19, 28, 30, 31, 37	none
mpu-thin	2, 5, 7, 9, 17, 20, 21	10, 16, 18, 19, 25	none

In both, every elem entry is cabi_realloc, __link_custom_section_describing_imports,
or core::fmt::…Display::fmt — all of which compile fine. The declined functions
are ordinary internals.

Incidentally this also explains a detail from my original report: switch-thin
declines 13 functions but shows only 10 dangling symbols. The other three
(23, 32, 33) are simply not referenced by any retained code once the declines
happen — not table-referenced, just dead.

So: no repro from us. Stated as a negative result rather than silence, since
"we checked our two candidates and neither is one" is at least a bound on where
it is not.

On our side

We are pinned to 0.58.0 and will pick up #1104 when it lands in a tag. Our gate
carries the 13 affected drivers on an explicit ledger that fails if a driver
starts crossing cleanly — so when we pin a build with the fix, the gate will go
red and force the ledger to shrink rather than let it quietly outlive the bug.
Given your no-regression sweep found 3 fixtures that now decline, I expect our 12
dangling objects to become 12 clean refusals, which is the correct outcome and
which our RV32 silicon work then waits on rather than being falsely unblocked by.