cfallin opened PR #11783 from cfallin:stack-iterator to bytecodealliance:main:
This will be desirable to allow a lazy stack-walk for our guest debugging API. It provides a
frame_iterator()function that produces an iterator over frames in one Wasm activation, factoring out the heart ofvisit_frames;visit_framesis now a thin wrapper around this iterator. No functional change expected.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
cfallin requested pchickey for a review on PR #11783.
cfallin requested wasmtime-core-reviewers for a review on PR #11783.
alexcrichton submitted PR review:
Can you expand the safety documentation further to include the new caveat that the iterator can't be moved around and basically needs to be consumed ASAP? For example it's possible to stash this iterator somewhere else and then try to read it later after returning, in theory, which would be quite bad (but this wasn't possible with the previous interface)
cfallin updated PR #11783.
cfallin commented on PR #11783:
Good call, thanks! Added.
cfallin has enabled auto merge for PR #11783.
alexcrichton commented on PR #11783:
wat.
cfallin commented on PR #11783:
Something weird is going on in the release build for macos-x86_64 here:
= note: Undefined symbols for architecture x86_64: "wasmtime::runtime::vm::stack_switching::stack::unix::x86_64::wasmtime_continuation_start::h6f90f069cad1fb0f", referenced from: wasmtime::runtime::vm::libcalls::cont_new::h036f758cc421dfe8 in libwasmtime-d96af5e94c417052.rlib[6](wasmtime-d96af5e94c417052.wasmtime.2f76dd9f0dfd2eb2-cgu.03.rcgu.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)This PR doesn't change anything related to stack-switching etc -- I wonder if this is some toolchain update related to macos x86_64 deprecation? I can't imagine what else it might be...
alexcrichton commented on PR #11783:
I can at least reproduce this locally, and it looks to rely on precise sets of flags/features so it's not the easiest to reproduce. Unfortunately https://github.com/bytecodealliance/wasmtime/pull/11787 doesn't help this. Looks like this doesn't show up on beta or nightly, however, so might be a bug fix in an upcoming version of Rust. I'll try to fix the configuration here
alexcrichton updated PR #11783.
alexcrichton requested wasmtime-default-reviewers for a review on PR #11783.
alexcrichton commented on PR #11783:
Ok looks like CI passed but it hit a merge conflict with #11787, so I'll let you handle the rebase/merge and queue this back up
cfallin updated PR #11783.
cfallin commented on PR #11783:
Thanks for the fix!
cfallin has enabled auto merge for PR #11783.
cfallin merged PR #11783.
Last updated: Dec 06 2025 at 06:05 UTC