Wasmtime GitHub notifications bot (Mar 25 2021 at 05:27): Wasmtime GitHub notifications bot (Mar 25 2021 at 05:27):cfallin opened PR #2763 from fix-srem-trap to main:
The codegen for div/rem ops has two modes, depending on the
avoid_div_trapsflag: it can either do all checks for trapping
conditions explicitly, and use explicit trap instructions, then use a
hardware divide instruction that will not trap (avoid_div_traps == true); or it can run in a mode where a hardware FP fault on the divide
instruction implies a Wasm trap (avoid_div_traps == false). Wasmtime
uses the former while Lucet (for example) uses the latter.It turns out that because we run all our spec tests run under Wasmtime,
we missed a spec corner case that fails in the latter: INT_MIN % -1 == 0
per the spec, but causes a trap with the x86 signed divide/remainder
instruction. Hence, in Lucet, this specific remainder computation would
incorrectly result in a Wasm trap.This PR fixes the issue by just forcing use of the explicit-checks
implementation forsremeven whenavoid_div_trapsis false.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Mar 25 2021 at 05:27):cfallin requested bnjbvr for a review on PR #2763.
Wasmtime GitHub notifications bot (Mar 25 2021 at 05:27):cfallin edited PR #2763 from fix-srem-trap to main:
The codegen for div/rem ops has two modes, depending on the
avoid_div_trapsflag: it can either do all checks for trapping
conditions explicitly, and use explicit trap instructions, then use a
hardware divide instruction that will not trap (avoid_div_traps == true);
or it can run in a mode where a hardware FP fault on the divide
instruction implies a Wasm trap (avoid_div_traps == false). Wasmtime
uses the former while Lucet (for example) uses the latter.It turns out that because we run all our spec tests run under Wasmtime,
we missed a spec corner case that fails in the latter: INT_MIN % -1 == 0
per the spec, but causes a trap with the x86 signed divide/remainder
instruction. Hence, in Lucet, this specific remainder computation would
incorrectly result in a Wasm trap.This PR fixes the issue by just forcing use of the explicit-checks
implementation forsremeven whenavoid_div_trapsis false.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
Wasmtime GitHub notifications bot (Mar 25 2021 at 05:33):cfallin updated PR #2763 from fix-srem-trap to main.
Wasmtime GitHub notifications bot (Mar 25 2021 at 06:42):bnjbvr submitted PR Review.
Wasmtime GitHub notifications bot (Mar 25 2021 at 06:58):cfallin merged PR #2763.
Last updated: Dec 23 2024 at 12:05 UTC