Stream: git-wasmtime

Topic: wasmtime / issue #5518 Cranelift: can we get rid of `debu...

view this post on Zulip Wasmtime GitHub notifications bot (Jan 11 2023 at 16:48):

fitzgen edited issue #5518:

I think these were a SpiderMonkey-ism? Unused now, AFAICT.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 11 2023 at 16:57):

bjorn3 commented on issue #5518:

Note that debug_trap must keep int3 as lowering. Otherwise debuggers get confused. This could be done by adding a trap code for a breakpoint. I don't think there is precedent for changing codegen depending on the trap code though. I believe it is currently extra information that can be stored in a side table.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 18:52):

fitzgen closed issue #5518:

I think these were a SpiderMonkey-ism? Unused now, AFAICT.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 18:52):

fitzgen commented on issue #5518:

I think we must have gotten rid of this at some point, because debug_trap no longer exists in the code base.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:08):

bjorn3 commented on issue #5518:

It is now called debugtrap and still used by cg_clif for implementing the breakpoint rust intrinsic.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:22):

fitzgen commented on issue #5518:

Yeah, I actually discovered the renaming that took place at some point just now as well.

Is there a reason that cg_clif has to use debugtrap instead of a normal trap?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:25):

bjorn3 commented on issue #5518:

trap generates ud2 which is not resumable and produces SIGILL, while debugtrap generates int3 which is resumable and which debuggers handle identical to a breakpoint set using the debugger itself.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:28):

fitzgen commented on issue #5518:

Gotcha.

FWIW, debugtrap produces hlt, not int3, on x64 right now. I guess this doesn't matter though?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:32):

bjorn3 commented on issue #5518:

It actually generates int3, but the instruction is called wrong in the Cranelift backend: https://github.com/bytecodealliance/wasmtime/blob/34b6b6738e22e13e66336a28fb4f1a1beb3e46e5/cranelift/codegen/src/isa/x64/inst/emit.rs#L4018-L4020 0xcc is int3. hlt would be 0xf4.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:32):

bjorn3 edited a comment on issue #5518:

It actually generates int3, but the instruction is called wrong in the x86_64 backend: https://github.com/bytecodealliance/wasmtime/blob/34b6b6738e22e13e66336a28fb4f1a1beb3e46e5/cranelift/codegen/src/isa/x64/inst/emit.rs#L4018-L4020 0xcc is int3. hlt would be 0xf4.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:33):

bjorn3 edited a comment on issue #5518:

It actually generates int3, but the instruction is called wrong in the x86_64 backend: https://github.com/bytecodealliance/wasmtime/blob/34b6b6738e22e13e66336a28fb4f1a1beb3e46e5/cranelift/codegen/src/isa/x64/inst/emit.rs#L4018-L4020 0xcc is int3[^1]. hlt would be 0xf4[^2].

[^1]: https://www.felixcloutier.com/x86/intn:into:int3:int1
[^2]: https://www.felixcloutier.com/x86/hlt

view this post on Zulip Wasmtime GitHub notifications bot (Jun 14 2024 at 19:58):

fitzgen commented on issue #5518:

Good to know. Either way, it seems like we shouldn't actually get rid of this, so I'm leaving the issue closed.

Last updated: Dec 23 2024 at 12:05 UTC