alexcrichton opened PR #11553 from alexcrichton:float-abis-are-weird to bytecodealliance:main:
... And then also add an escape hatch to allow loading code. This commit is the culmination of discussion on #11506 with a proposed resolution for Wasmtime. The resolution being:
- Wasmtime will reject loading code on
x86_64-unknown-noneplatforms by default.- A new
Config::x86_float_abi_okescape hatch is added to bypass this check.- Documentation/errors are updated around
x86_float_abi_okto document the situation.- The
min-platformexample is updated to showcase how this is valid to run in that particular embedding (aka enable more features and sufficiently detect said features).The basic tl;dr; is that we can't detect in stable Rust what float ABI is being used so therefore we pessimistically assume that
x86_64-unknown-noneis using a soft-float ABI. This is incompatible with libcalls unless they aren't actually called which is only possible when sufficiently many target features are enabled.The goal of this commit is to be a relatively low-effort way to place a roadblock in the way of "ok ABIs are weird" but at the same time enable getting around the roadblock easily. Additionally the roadblock points to documentation about itself to learn more about what's going on here.
Closes #11506
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested dicej for a review on PR #11553.
alexcrichton requested wasmtime-core-reviewers for a review on PR #11553.
alexcrichton requested wasmtime-default-reviewers for a review on PR #11553.
alexcrichton commented on PR #11553:
For posterity @fitzgen I tried to get
min-platformworking on aarch64-unknown-none but there's relocation errors about compilinglibembedding.a(Rust code foraarch64-unknown-none) into a Linux shared library. I don't know how to resolve the errors without first going off and memorizing a bunch of relocation/shared-object things about aarch64...
alexcrichton updated PR #11553.
alexcrichton updated PR #11553.
cfallin submitted PR review:
Thanks for following up from our Cranelift meeting discussion! A minor documentation thought below in the example but otherwise this looks workable for us at least...
cfallin created PR review comment:
s/affect/effect/
It does likely have an affect, namely that it's mildly sad that it has to exist...
(with apologies for the spelling pedantry!)
cfallin created PR review comment:
Looking this up to verify -- this has existed since 2013 (Haswell) on Intel chips and 2012 (Piledriver) on AMD chips so it's probably fine for anyone wanting to actually run the example on a semi-modern dev machine or server. Perhaps we want to put a comment here ("Note: these features should be present on Intel Haswell (2013) / AMD Piledriver (2012) or later; make sure to run this example on such a platform.") next to the config?
jsturtevant submitted PR review.
jsturtevant created PR review comment:
All of these features are required to bypass the
libcallsor just a subset?
github-actions[bot] commented on PR #11553:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Configmethod, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Configmethod, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nestedstructs).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
alexcrichton updated PR #11553.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
SE4.1 is sufficient if you're not using relaxed-simd, but with relaxed-simd you'll also need FMA.
alexcrichton has enabled auto merge for PR #11553.
alexcrichton updated PR #11553.
alexcrichton has enabled auto merge for PR #11553.
alexcrichton merged PR #11553.
Last updated: Dec 06 2025 at 06:05 UTC