Stream: git-wasmtime

Topic: wasmtime / Issue #1148 Don't save/restore the stack if it...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 13 2020 at 04:38):

kevinwern commented on Issue #1148:

Hi, is this bug being still being worked on? Interested in taking it on if not.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 16 2020 at 12:51):

bnjbvr commented on Issue #1148:

I think a patch has been made to fix the double negative issue mentioned in https://github.com/bytecodealliance/wasmtime/issues/1148#issuecomment-557645797, but the initial issue hasn't been fixed yet, as far as i can tell!

view this post on Zulip Wasmtime GitHub notifications bot (Aug 17 2020 at 06:56):

BK1603 commented on Issue #1148:

Is someone still working on this?
If not then I'd like to take this up.

@kevinwern (pinging you since you seem to be the last person that took this up :P)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 17 2020 at 13:56):

bnjbvr commented on Issue #1148:

Not sure if this is still relevant: on the new backend, we do things very differently and have entirely rewritten this code. Would you like to investigate this further, you could try to compile a small wasm function with the new backend (cargo run --features experimental_x64 etc), on x86_64, and check whether it still spuriously allocates stack or not.


Last updated: Nov 22 2024 at 16:03 UTC