wasmtime / PR #11570 aarch64: Add support for "near" in `... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #11570 aarch64: Add support for "near" in `...

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:06):

alexcrichton opened PR #11570 from alexcrichton:aarch64-near-symbol to bytecodealliance:main:

The current aarch64 backend does not support symbol_value to get the value of a function, for example, with a "near" relocation using a relative relocation. Currently it uses an Abs8 relocation which means that it's not suitable in Wasmtime, for example.

This commit refactors relocation/external name support in the aarch64 backend to support this mode of relocation. The previous LoadExtName was split into LoadExtName{Got,Near,Far} where the "near" bit is what's new to the backend. The preexisting symbol-value.clif-style tests were updated to match the x64 backend which has a more comprehensive suite of examples of what it looks like to refer to various symbols.

The goal of this commit is to enable Wasmtime to generate code which refers to a relative point elsewhere in the code (e.g. an exception handler) and load the value into a register. This part isn't filled out yet, but it seemed good to at least in the meantime fill out these missing relocations in the backend.

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:06):

alexcrichton requested cfallin for a review on PR #11570.

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:06):

alexcrichton requested wasmtime-compiler-reviewers for a review on PR #11570.

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:39):

cfallin submitted PR review:

Thanks! This definitely makes sense to have.

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:39):

cfallin created PR review comment:

On looking a bit further, it seems that Function::is_leaf only looks to see if there are signatures -- so func_addr triggers the "not a leaf function" mode and forces the frame.

Mind filing an issue that we should probably determine leaf-ness by scanning VCode instead for any instructions that claim to be calls? It should be machine-dependent anyway since libcalls can happen even in functions without IR-level calls. (I suppose that is_leaf and the no-frame ABI optimization isn't even right, in that case -- but we get away with it because the aarch64 backend doesn't fall back to any libcalls for FP stuff, and also because this configuration isn't exposed to Wasmtime?)

Wasmtime GitHub notifications bot (Aug 29 2025 at 18:39):

cfallin created PR review comment:

Sort of curious that the leaf-function optimization is no longer happening here, and we're getting a frame now -- won't matter for Wasmtime since we always force frames, but is there a reason you're aware of that this is happening?

Wasmtime GitHub notifications bot (Aug 29 2025 at 20:44):

github-actions[bot] commented on PR #11570:

Subscribe to Label Action

cc @cfallin, @fitzgen

<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "isle"

Thus the following users have been cc'd because of the following labels:

cfallin: isle

fitzgen: isle

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:15):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:15):

alexcrichton created PR review comment:

Sure thing! https://github.com/bytecodealliance/wasmtime/issues/11573

And yeah AFAIK we're ok in Wasmtime, but I''m not 100% sure in that judgment. Your reasoning sounds reasonable to me, however

Wasmtime GitHub notifications bot (Aug 29 2025 at 21:58):

alexcrichton updated PR #11570.

Wasmtime GitHub notifications bot (Aug 30 2025 at 00:06):

alexcrichton has enabled auto merge for PR #11570.

Wasmtime GitHub notifications bot (Aug 30 2025 at 00:34):

alexcrichton merged PR #11570.

Last updated: Dec 06 2025 at 06:05 UTC