Skip to content

Check the type of __wasm_call_ctors and __wasm_apply_data_relocs - #2699

Merged
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
Lstarsky0:fix/link-check-func-types
Sep 30, 2026
Merged

alexcrichton merged 1 commit into
bytecodealliance:mainfrom
Lstarsky0:fix/link-check-func-types

Conversation

@Lstarsky0

Copy link
Copy Markdown
Contributor

The linker calls __wasm_call_ctors and __wasm_apply_data_relocs as [] -> [], but when it reads a library it only notes that they're exported. A library exporting one with a different type still links, and the problem shows up at the very end:

failed to validate component output
type mismatch for export `__wasm_call_ctors` of module instantiation argument `app.wasm`
expected: (func)
found:    (func (param i32))

or as an invalid component with --skip-validation. This checks both when the library is read, with the same message #2646 uses for the intrinsic imports:

failed to extract linking metadata from app.wasm: type mismatch for export `__wasm_call_ctors`: required linker ABI `[] -> []` but found `[I32] -> []`

_initialize and _start are called the same way, but a wrong type there is already caught when the encoder classifies the exports, so I left them alone.

The new error-link-ctors-signature test fails without the change.

Refs #2591

The linker's start function calls both as `[] -> []`, but metadata
extraction only recorded that they were exported. A library exporting
either with another type still linked: `wasm-tools component link` then
failed validation of the result with a type mismatch on a module
instantiation argument, and with validation off (the `ComponentEncoder`
default) the invalid component was returned. Check them when the
metadata is read, with the same message the intrinsic imports use.

`_initialize` and `_start` are left alone: the component encoder already
rejects those with the wrong type when it classifies the exports.

Refs bytecodealliance#2591
@Lstarsky0
Lstarsky0 requested a review from a team as a code owner September 30, 2026 11:13
@alexcrichton
alexcrichton added this pull request to the merge queue Sep 30, 2026
Merged via the queue into bytecodealliance:main with commit b552a4f Sep 30, 2026
37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants