Callable Functions vs Resume Entries: Function Ownership and Stack Contracts
Status: IMPLEMENTATION FACT / DERIVED · Evidence: synthetic behavioral regression and current public source · Last reviewed: 2026-08-11
The boundary
A valid resume program counter is not automatically a callable function boundary. Static recompilation must distinguish a host-callable wrapper, which establishes a fresh call frame, from a resume entry, which continues an owner function after the owner has already lowered its frame. Treating every recovered address as callable can corrupt the stack contract even when the translated instructions look plausible.
Two contracts
| Entry kind | Frame ownership | Host behavior |
|---|---|---|
| Callable | standalone function owns its frame | capture the caller stack pointer, enter f_<addr>, and restore the caller value at the wrapper boundary |
| Resume | owner function already lowered the frame | enter r_<addr> in the owner’s frame; do not capture or restore a new entry stack pointer |
In the current code-generation model, EntryInfo records callable, resumable, owner, and provenance. Callable entries use f_ symbols; resume entries use r_ symbols. The owner CFG retains the resume region as native continuation code, while dispatch registers the resume entry separately.
Synthetic regression
The regression uses a source-owned fixture rather than a retail address. Before the fix, the resume path observed _sp_entry = 0x00000f90 while the caller supplied 0x00001000; the difference was the owner’s lowered frame. After separating the contracts, the callable wrapper restores the caller value and the resume path leaves the owner frame untouched. This is production code-generation behavior exercised through a synthetic fixture, not hardware evidence.
callable wrapper: save caller_sp; f_entry(); restore caller_sp
resume entry: r_entry(); return through owner epilogueStop conditions
A dual-role address, multiple resume owners, or unresolved ownership is a stop-and-report condition. It should not be “resolved” with a function-shaped heuristic. The corresponding analysis and regex-backed regression are documented in docs/issue-51-entry-semantics.md; the implementation lives in the public entry catalog, entry-symbol policy, and emission path.
How to review a claim
Record the entry address, owner, frame state, symbol kind, and dispatch registration separately. Then classify the result under the Evidence Standard. The PSP Executable Model explains why a control-flow target can be a continuation without being an exported function, while the Static Recompilation Architecture shows where the distinction enters the pipeline.
Related reading: Nakagawa Recomp Case Study and Open Research Questions.