<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in stack.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>980a136e - Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#980a136e</link>
        <description>Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)* Wasmtime: generalize `async_stack_zeroing` knob to cover initializationThis commit moves the knob from the `PoolingInstanceAllocatorConfig` to theregular `Config` and now controls both whether stacks are zeroed before reuseand whether they are zeroed before the initial use. The latter doesn&apos;t matterusually, since anonymous mmaps are already zeroed so we don&apos;t have to doanything there, but for no-std environments it is the difference betweenmanually zeroing the stack or simply using unininitialized memory.* Fix CLI and test builds* fix default config value* fix some more tests

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Thu, 16 Jan 2025 00:23:13 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>abcd6acc - Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#abcd6acc</link>
        <description>Port wasmtime-fiber to `no_std` and allow `async` feature in `no_std` Wasmtime. (#9689)This PR allows a `no_std` Wasmtime build to be configured with the`async` feature. (Previously, a minimal `no_std` configuration couldonly run with sync entry points, without suspending of stacks.)The main hurdle to this support was the `wasmtime-fiber` crate.Fortunately, the &quot;unix&quot; variant of fibers was almost entirely portableto a `no_std` environment, owing to the fact that it implementsstack-switching manually in assembly itself. I moved the per-ISAimplementations to a shared submodule and built the nostd platformbackend for `wasmtime-fiber` with a stripped-down version of the unixbackend.The nostd backend does not support mmap&apos;d stacks, does not supportcustom stack allocators, and does not propagate panics.prtest:full

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Wed, 04 Dec 2024 19:31:21 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>110e70f3 - Print an error on async stack overflow (#9304)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#110e70f3</link>
        <description>Print an error on async stack overflow (#9304)* Print an error on async stack overflowThis commit updates Wasmtime&apos;s handling of traps on Unix platforms toprint an error message on stack overflow when the guard page is hit.This is distinct from stack overflow in WebAssembly which raises anormal trap and can be caught. This is instead to be used onmisconfigured hosts where the async stack is too small or wasm wasallowed to take up too much of the async stack. Currently no errormessage is printed and the program simply aborts with a core dump whichcan be difficult to debug.This instead registers the range of the async guard page with the traphandling infrastructure to test the faulting address and if it lieswithin this range. If so then a small message is printed and then theprogram is aborted with `libc::abort()`.This does not impact the safety of any prior embedding or fix anyissues. It&apos;s instead intended purely as a diagnostic tool to help usersmore quickly understand that stack size configuration settings are thelikely culprit.* Fix build of c-api and testsprtest:full* Fix build on Windows* Fix a warning on Windows* Fix dead code on miri

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Thu, 26 Sep 2024 04:12:12 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#1512a954</link>
        <description>Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc`

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Fri, 14 Jun 2024 15:24:12 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#81a89169</link>
        <description>Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime&apos;s platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren&apos;t implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime&apos;s TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the &quot;custom&quot; platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can&apos;t be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn&apos;t enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime&apos;s `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Sat, 04 May 2024 22:02:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>d4242001 - Support compilation-only build by adding a `runtime` feature (#7766)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs#d4242001</link>
        <description>Support compilation-only build by adding a `runtime` feature (#7766)* Add `runtime` feature to `wasmtime` crateThis feature can be disabled to build `wasmtime` only for compilation.This can be useful when cross-compiling, especially on a target thatcan&apos;t run wasmtime itself (e.g. `wasm32`).* prtest:full* don&apos;t round pages without runtime feature* fix async assertions* move profiling into runtime* enable runtime for wasmtime-wasi* enable runtime for c-api* fix build_artifacts in non-cache case* fix miri extensions* enable runtime for wast* enable runtime for explorer* support cranelift all-arch on wasm32* add doc links for `WeakEngine`* simplify lib runtime cfgs* move limits and resources to runtime* move stack to runtime* move coredump and debug to runtime* add runtime to coredump and async features* add wasm32 build job* combine engine modules* single compile mod* remove allow for macro paths* add comments

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/stack.rs</description>
        <pubDate>Mon, 29 Jan 2024 15:51:43 +0000</pubDate>
        <dc:creator>Adam Bratschi-Kaye &lt;adam.bratschikaye@dfinity.org&gt;</dc:creator>
    </item>
</channel>
</rss>
