Fix incomplete trap metadata due to multiple traps at one address. #2685
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If an instruction has more than one trap record associated with it (for example: a divide instruction that has participated in load-op fusion, so we have both a heap-out-of-bounds trap record due to its load and a divide-by-zero trap record due to its divide op), the current MachBuffer code would emit only one of the trap records to the sink. Separately, divide instructions probably shouldn't merge loads, because the two separate possible traps at one location might be confusing for some embedders (certainly in Lucet). Divide seems to be the only case in our current codegen where such merging might occur. This PR changes the lowering to always force the divisor into a register. Finally, while working out why trap records were not appearing, I had noticed that `isa::x64::emit_std_enc_mem()` was only emitting heap-OOB trap metadata for loads/stores when it had a srcloc. This PR ensures that the metadata is emitted even when the srcloc is empty. Note that none of the above presents a security or correctness problem; trap metadata only affects the status that we return to the embedder when a Wasm program terminates with a trap.
github-actions
bot
added
cranelift
cfallin
added a commit
to bytecodealliance/lucet
that referenced
this pull request
Feb 25, 2021
pchickey
pushed a commit
to bytecodealliance/lucet
that referenced
this pull request
Feb 25, 2021
jameysharp
added a commit
to jameysharp/wasmtime
that referenced
this pull request
Mar 13, 2024
In bytecodealliance#2426, @cfallin wrote: > […] don't emit trap info unless an op can trap. > > This end result was previously enacted by carrying a SourceLoc on > every load/store, which was somewhat cumbersome, and only indirectly > encoded metadata about a memory reference (can it trap) by its > presence or absence. That PR changed both backends that existed at the time to check both the source location and the memory flags to determine whether a memory access could trap. Then in bytecodealliance#2685, @cfallin wrote: > Finally, while working out why trap records were not appearing, I had > noticed that isa::x64::emit_std_enc_mem() was only emitting heap-OOB > trap metadata for loads/stores when it had a srcloc. This PR ensures > that the metadata is emitted even when the srcloc is empty. However that PR did not apply the same change to other backends. Since then, the pattern from bytecodealliance#2426 has been copied to new backends. I believe checking the source location has been unnecessary since bytecodealliance#2426 and is now just a source of confusion at best, and possibly bugs at worst. So this PR makes all targets match the behavior of the x64 backend. In addition, this pattern was the only reason why source locations were provided to any backend's emit state, so I'm removing that entirely. The `cur_srcloc` field has been unused on x64 since bytecodealliance#2685. This change is mostly straightforward, but there are two questionable changes in the riscv64 backend: - The riscv64 backend had one use of this pattern for a BadConversionToInteger trap. All other uses on all backends were for HeapOutOfBounds traps. I suspect that was a copy-paste bug so I've removed it just like all the others. - The riscv64 `Inst::Atomic` does not have a MemFlags field, so this means the HeapOutOfBounds trap metadata is added unconditionally for such instructions.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 13, 2024
* cranelift: Remove srcloc from emit state on all targets In #2426, @cfallin wrote: > […] don't emit trap info unless an op can trap. > > This end result was previously enacted by carrying a SourceLoc on > every load/store, which was somewhat cumbersome, and only indirectly > encoded metadata about a memory reference (can it trap) by its > presence or absence. That PR changed both backends that existed at the time to check both the source location and the memory flags to determine whether a memory access could trap. Then in #2685, @cfallin wrote: > Finally, while working out why trap records were not appearing, I had > noticed that isa::x64::emit_std_enc_mem() was only emitting heap-OOB > trap metadata for loads/stores when it had a srcloc. This PR ensures > that the metadata is emitted even when the srcloc is empty. However that PR did not apply the same change to other backends. Since then, the pattern from #2426 has been copied to new backends. I believe checking the source location has been unnecessary since #2426 and is now just a source of confusion at best, and possibly bugs at worst. So this PR makes all targets match the behavior of the x64 backend. In addition, this pattern was the only reason why source locations were provided to any backend's emit state, so I'm removing that entirely. The `cur_srcloc` field has been unused on x64 since #2685. This change is mostly straightforward, but there are two questionable changes in the riscv64 backend: - The riscv64 backend had one use of this pattern for a BadConversionToInteger trap. All other uses on all backends were for HeapOutOfBounds traps. I suspect that was a copy-paste bug so I've removed it just like all the others. - The riscv64 `Inst::Atomic` does not have a MemFlags field, so this means the HeapOutOfBounds trap metadata is added unconditionally for such instructions. * Filetests don't have srclocs so they get traps now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If an instruction has more than one trap record associated with it (for
example: a divide instruction that has participated in load-op fusion,
so we have both a heap-out-of-bounds trap record due to its load and a
divide-by-zero trap record due to its divide op), the current MachBuffer
code would emit only one of the trap records to the sink.
Separately, divide instructions probably shouldn't merge loads, because
the two separate possible traps at one location might be confusing for
some embedders (certainly in Lucet). Divide seems to be the only case in
our current codegen where such merging might occur. This PR changes the
lowering to always force the divisor into a register.
Finally, while working out why trap records were not appearing, I had
noticed that
isa::x64::emit_std_enc_mem()was only emitting heap-OOBtrap metadata for loads/stores when it had a srcloc. This PR ensures
that the metadata is emitted even when the srcloc is empty.
Note that none of the above presents a security or correctness problem;
trap metadata only affects the status that we return to the embedder
when a Wasm program terminates with a trap.