github-actions[bot] commented on Issue #1490:
Subscribe to Label Action
This issue or pull request has been labeled: "cranelift", "fuzzing", "wasmtime:api", "wasmtime:c-api"
<details> <summary>Users Subscribed to "cranelift"</summary>
- @bnjbvr
</details>
<details> <summary>Users Subscribed to "fuzzing"</summary>
- @fitzgen
</details>
<details> <summary>Users Subscribed to "wasmtime:api"</summary>
- @peterhuene
</details>
<details> <summary>Users Subscribed to "wasmtime:c-api"</summary>
- @peterhuene
</details>
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
fitzgen commented on Issue #1490:
Haven't looked at the code yet, but I have a question:
The
wasmtime::Store
type has a
method to acquire anInterruptHandle
,Does this mean that the finest granularity of interrupt is a store?
That seems fine for now, in the single-threaded wasm world, but will likely need reworking to be finer grained when we support threads. Do you have an idea how much more work it would be to make this per-instance?
alexcrichton commented on Issue #1490:
@fitzgen yeah adapting this shouldn't be too hard at all, it's just a shared
Arc
data structure and it would be easy to arrange all instances linked together to have access to thatArc
github-actions[bot] commented on Issue #1490:
Subscribe to Label Action
This issue or pull request has been labeled: "wasi"
<details> <summary>Users Subscribed to "wasi"</summary>
- @kubkon
</details>
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
alexcrichton commented on Issue #1490:
Ok I've pushed up a commit which uses a
GlobalValue
for the stack limit instead of a closure, and there's a "mini interpreter" of thisGlobalValue
sinceins().global_value(...)
can't be used this late after legalization. It's hopefully sufficient enough for now but also with better future-compatibility.I'm not really sure how to serialize this out or parse it in the text format. If that's required can folks point me in the right direction of how to do that?
bjorn3 commented on Issue #1490:
You should serialize it in
write_function
and then parse it incranelift-reader
.
alexcrichton commented on Issue #1490:
Ok @sunfishcode, should be updated!
alexcrichton commented on Issue #1490:
Ok after some discussion with @sunfishcode I brought back the
SA_ONSTACK
flag so we can be sure to still execute the fallback to libstd's segfault handler on the sigaltstack. We already have the code to make the sigaltstack bigger, so that should cover our own purposes for now as well. This means that all signals still go through the sigaltstack.
alexcrichton commented on Issue #1490:
Ok the last commit should be the stack limit parsing via the syntax you suggested
sunfishcode commented on Issue #1490:
Looks good! There's now just the two CI failures. One is an easy fix I just commented on above.
There other is a failure in host_segfault.rs on macos-latest CI:
Running target/release/deps/host_segfault-de61d05b549d9afb thread 'main' panicked at 'assertion failed: stderr.contains("thread 'main' has overflowed its stack")', tests/host_segfault.rs:95:9 stack backtrace: 0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt 1: core::fmt::write 2: std::io::Write::write_fmt 3: std::panicking::default_hook::{{closure}} 4: std::panicking::default_hook 5: std::panicking::rust_panic_with_hook 6: std::panicking::begin_panic 7: host_segfault::main 8: std::rt::lang_start::{{closure}} 9: std::panicking::try::do_call 10: __rust_maybe_catch_panic 11: std::rt::lang_start_internal 12: main
alexcrichton commented on Issue #1490:
Ok all green now!
sunfishcode commented on Issue #1490:
Great!
Last updated: Dec 23 2024 at 12:05 UTC