Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

* Migrate wasmtime-cli to `wasmtime::error`

* migrate benches to `wasmtime::error` as well

* Remove new usage of anyhow that snuck in

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Add Engine/Component::deserialize_raw (#10321)

* Add Engine/Component::deserialize_raw

For targets without virtual memory support, the only mechanism for
load code previously was to copy bytes from

Add Engine/Component::deserialize_raw (#10321)

* Add Engine/Component::deserialize_raw

For targets without virtual memory support, the only mechanism for
load code previously was to copy bytes from a provided slice into
a separate, owned, allocated buffer containing a copy of the serialized
module contents. This is expensive for constrained targets and
prohibits embedded runtimes like doing things like running code
directly out of memory-mapped devices such as NOR flash.

The tradeoff for directly using the externally owned memory is that
the caller must ensure that the code memory will not be written
to for the lifetime of the CodeMemory.

Loading code from externally owned memory is supported for all
configurations but is expected to fail to deserialize on platforms
that suport virtual memory and are attempting to load modules
or components that require that the memory be made executable
(native code rather than pulley).

https://github.com/bytecodealliance/wasmtime/issues/10245

* Fix tests for s390x

Previously, there was a bad assumption that pulley32/64 were the
only targets but there's also the "be" variants. Use the
`pulley_host` helper to better get the right pulley target
for the host.

show more ...

Optimize MIRI execution time in CI (#10038)

* Optimize MIRI execution time in CI

* Disable Cranelift optimizations and use single_pass register
allocation by default.

* Ignore a number of tests

Optimize MIRI execution time in CI (#10038)

* Optimize MIRI execution time in CI

* Disable Cranelift optimizations and use single_pass register
allocation by default.

* Ignore a number of tests that are compiling wasm which we generally
don't want to do under MIRI.

* Fix CI build

show more ...

Run the full test suite on 32-bit platforms (#9837)

* Run the full test suite on 32-bit platforms

This commit switches to running the full test suite in its entirety
(`./ci/run-tests.sh`) on 32-bit

Run the full test suite on 32-bit platforms (#9837)

* Run the full test suite on 32-bit platforms

This commit switches to running the full test suite in its entirety
(`./ci/run-tests.sh`) on 32-bit platforms in CI in addition to 64-bit
platforms. This notably adds i686 and armv7 as architectures that are
tested in CI.

Lots of little fixes here and there were applied to a number of tests.
Many tests just don't run on 32-bit platforms or a platform without
Cranelift support, and they've been annotated as such where necessary.
Other tests were adjusted to run on all platforms a few minor bug fixes
are here as well.

prtest:full

* Fix clippy warning

* Get wasm code working by default on 32-bit

Don't require the `pulley` feature opt-in on 32-bit platforms to get
wasm code running.

* Fix dead code warning

* Fix build on armv7

* Fix test assertion on armv7

* Review comments

* Update how tests are skipped

* Change how Pulley is defaulted

Default to pulley in `build.rs` rather than in `Cargo.toml` to make it
easier to write down the condition and comment what's happening. This
means that the `pulley-interpreter` crate and pulley support in
Cranelift is always compiled in now and cannot be removed. This should
hopefully be ok though as the `pulley-interpreter` crate is still
conditionally used (meaning it can get GC'd) and the code-size of
Cranelift is not as important as the runtime itself.

* pulley: Save/restore callee-save state on traps

* Fewer clippy warnings about casts

* Use wrapping_add in `g32_addr`, fixing arm test

show more ...

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the previously added `signals-based-traps` feature in
favor of auto-detecting whether it's there or not. The `build.rs`
script for the `wasmtime` crate will now detect the target platform and
auto-enable this feature as necessary.

The `signals-based-traps` cargo feature is removed and split into two
custom `#[cfg]` directives that the build script sets:

* `has_virtual_memory` - this is used to gate mmap implementations for
example. This is enabled on `unix || windows` and will be off for
`no_std` targets for example. This is split out of
"signals-based-traps" to better handle platforms like iOS which have
virtual memory but don't execute native code (removing the need for
native signals).

* `has_native_signals` - gates signal handlers on Unix for example. This
is disabled on MIRI but otherwise enabled for `unix || windows`. This
is intended to in the future get disabled for iOS by default for
example since it's not necessary when using Pulley. This is
additionally off-by-default for `no_std` platforms.

Two new crate features were added for `no_std` or "custom" platforms to
opt-in to the `wasmtime-platform.h` C APIs for implementing virtual
memory and signals. These are used in the `min-platform` embedding example.

This commit additionally updates some various documentation here and
there to be more up-to-date.

* Update CI configuration

* Fix compile warnings

* Fix test on miri

* Fix more tests on miri

* Fix some warnings

* Another round of miri/CI attempts/fixes

prtest:full

show more ...

Make module validation deterministic in case of multiple errors (#9947)

* make validation deterministic in case of multiple errors

* test flag

* smaller test

---------

Co-authored-by: Michael We

Make module validation deterministic in case of multiple errors (#9947)

* make validation deterministic in case of multiple errors

* test flag

* smaller test

---------

Co-authored-by: Michael Weigelt <[email protected]>

show more ...

Remove static/dynamic memories from public docs (#9545)

* Remove static/dynamic memories from public docs

This commit removes the terminology of "static" and "dynamic" memories
from the public-faci

Remove static/dynamic memories from public docs (#9545)

* Remove static/dynamic memories from public docs

This commit removes the terminology of "static" and "dynamic" memories
from the public-facing documentation of Wasmtime, notably on the
`Config` structure and its various configuration settings. The goal of
this commit is in the same vein as #9543 which is to simplify the memory
settings of Wasmtime for users in this case.

This change doesn't actually have any code changes beyond renames (and
handling now-deprecated CLI options). The goal of this commit is to
basically rewrite how we document the effect of various settings of
Wasmtime. Notably:

* `Config::static_memory_maximum_size` is now `memory_reservation`.
* `Config::static_memory_forced` is now `memory_reservation_is_maximum`.
* `Config::dynamic_memory_reserved_for_growth` is now
`memory_reservation_for_growth`.

Documentation for all of these options has been rewritten and updated to
take into account the removal of "dynamic" and "static" terminology.
Additionally more words have been written about the various effects of
each setting and how things related to wasm features such as index type
sizes and custom page sizes.

The rewritten documentation is intended to basically already match what
Wasmtime does today. I believe that all of these settings are useful in
one form or another so none have been dropped but the updated
documentation is intended to help simplify the mental model for how
they're processed internally and how they affect allocations and such.

* Fix how the setting is flipped

* Review comments

show more ...

Unbreak CI on release branch (#9411)

Ignore new tests on MIRI

prtest:full

Merge commit from fork

* Fix a race condition in the Wasm type registry

Under certain concurrent event orderings, the type registry was susceptible to
double-unregistration bugs due to a race condi

Merge commit from fork

* Fix a race condition in the Wasm type registry

Under certain concurrent event orderings, the type registry was susceptible to
double-unregistration bugs due to a race condition.

Consider the following example where we have threads `A` and `B`, an existing
rec group entry `E`, and another rec group entry `E'` that is a duplicate of
`E`:

| Thread A | Thread B |
|-----------------------------------|--------------------------------|
| `acquire(type registry lock)` | |
| | `decref(E) --> 0` |
| | `block_on(type registry lock)` |
| `register(E') == incref(E) --> 1` | |
| `release(type registry lock)` | |
| `decref(E) --> 0` | |
| `acquire(type registry lock)` | |
| `unregister(E)` | |
| `release(type registry lock)` | |
| | `acquire(type registry lock)` |
| | `unregister(E)` !!!!!! |

As you can see, in the above event ordering, we would unregister `E` twice,
leading to panics and potential type registry corruption.

This commit adds an `unregistered` flag to each entry which is set when we
commit to unregistering the entry and while we hold the type registry lock. When
we are considering unregistering an entry at the beginning of
`TypeRegistryInner::unregister_entry`, because we observed a zero-registrations
count for that entry and then waited on the type registry's lock, we now check
if that flag is already set (by some concurrent unregistration that happened
between observing the zero-registrations count and acquiring the lock) before we
actually perform the unregistration.

Furthermore, in the process of writing a smoke test for concurrent module (and
therefore type) loading and unloading, I discovered an index out-of-bounds panic
during Wasm-to-CLIF module translation. This commit also includes the one-line
fix for that bug and a `.wast` regression test for it as well.

* Update test to trigger case requiring `unregistered` flag

* Add another test further stressing concurrent interactions

Try to get a module's function type to get typed the wrong way and/or
get wasm to call with the wrong signature.

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Simplify ABI selection and tail call integration (#9061)

This commit simplifies the selection of an ABI for wasm functions now
that all Cranelift backends implement tail calls. All wasm functions us

Simplify ABI selection and tail call integration (#9061)

This commit simplifies the selection of an ABI for wasm functions now
that all Cranelift backends implement tail calls. All wasm functions use
the `Tail` calling convention except when the `winch_callable` tunable
is enabled meaning that Winch-generated functions are being called.

This then additionally simplifies the activation of the tail call
proposal. It's not unconditionally active and the same across all
compilers. The Winch compiler is updated to return an error for
unsupported instructions rather than panicking so the embedder API is
suitable for feeding unsupported modules to Winch. This means that tail
calls in Winch behaves similarly to GC in Cranelift or other unsupported
proposals like SIMD in Winch.

show more ...

s390x: Support tail calls (#9052)

This adds support for a newly defined tail-call ABI for s390x
as well as supporting tail calls themselves.

We now use the tail-call ABI by default for Wasmtime, an

s390x: Support tail calls (#9052)

This adds support for a newly defined tail-call ABI for s390x
as well as supporting tail calls themselves.

We now use the tail-call ABI by default for Wasmtime, and
enable tail calls by default.

This also allows getting rid of a number of special case
and test exclusions for s390x.

Fixes: https://github.com/bytecodealliance/wasmtime/issues/6530

show more ...

style: simplify string formatting (#9047)

* style: simplify string formatting

* fix: formatting in `benches/call.rs`

Wasmtime: remove indirect-call caching. (#8881)

In the original development of this feature, guided by JS AOT
compilation to Wasm of a microbenchmark heavily focused on IC sites, I
was seeing a ~20%

Wasmtime: remove indirect-call caching. (#8881)

In the original development of this feature, guided by JS AOT
compilation to Wasm of a microbenchmark heavily focused on IC sites, I
was seeing a ~20% speedup. However, in more recent measurements, on full
programs (e.g., the Octane benchmark suite), the benefit is more like
5%.

Moreover, in #8870, I attempted to switch over to a direct-mapped cache,
to address a current shortcoming of the design, namely that it has a
hard-capped number of callsites it can apply to (50k) to limit impact on
VMContext struct size. With all of the needed checks for correctness,
though, that change results in a 2.5% slowdown relative to no caching at
all, so it was dropped.

In the process of thinking through that, I discovered the current design
on `main` incorrectly handles null funcrefs: it invokes a null code pointer,
rather than loading a field from a null struct pointer. The latter was
specifically designed to cause the necessary Wasm trap in #8159, but I
had missed that the call to a null code pointer would not have the same
effect. As a result, we actually can crash the VM (safely at least, but
still no good vs. a proper Wasm trap!) with the feature enabled. (It's
off by default still.) That could be fixed too, but at this point with
the small benefit on real programs, together with the limitation on
module size for full benefit, I think I'd rather opt for simplicity and
remove the cache entirely.

Thus, this PR removes call-indirect caching. It's not a direct revert
because the original PR refactored the call-indirect generation into
smaller helpers and IMHO it's a bit nicer to keep that. But otherwise
all traces of the setting, code pre-scan during compilation and special
conditions tracked on tables, and codegen changes are gone.

show more ...

Make module ids unique per-process, not per-engine (#8758)

* Make module ids unique per-process, not per-engine

Currently all instances of `wasmtime::Module` have a unique 64-bit id
embedded into t

Make module ids unique per-process, not per-engine (#8758)

* Make module ids unique per-process, not per-engine

Currently all instances of `wasmtime::Module` have a unique 64-bit id
embedded into them. This ID was originally only used for affinity in the
pooling allocator as a quick check of module equality. This use case
only required engine-local ids so the initial implementation had an ID
allocator per-engine.

Later, however, this id was reused for `wasmtime::ModuleExport` which
was intended to skip the string lookup for an export at runtime. This
also stored a module id but it did not store an engine identifier. This
meant that it's possible to mix these up and pass the wrong export to
the wrong engine. This behavior can lead to a runtime panic in Wasmtime.

This commit fixes this by making the module identifier be global
per-process instead of per-engine. This mirrors how store IDs are
allocated where they're per-process instead of per-engine. The same
logic for why store IDs are unlikely to be exhausted applies here too
where this 64-bit space of identifiers is unlikely to be exhausted.

* Fix warnings

* Fix tests

show more ...

Fix tail calls being turned on by default (#8682)

* Fix tail calls being turned on by default

Logic in `Config` to conditionally enable tail calls wasn't handling the
case where the configured comp

Fix tail calls being turned on by default (#8682)

* Fix tail calls being turned on by default

Logic in `Config` to conditionally enable tail calls wasn't handling the
case where the configured compiler strategy was `Strategy::Auto` meaning
that by default tail calls weren't actually enabled. This commit
refactors handling of `Strategy` to avoid storing `Strategy::Auto` in
`CompilerConfig` so tests against it can use either cranelift or winch.

* Update disas tests

* Update Winch tests to using winch

show more ...

Call-indirect caching: protect against out-of-bounds table index during prescan. (#8541)

* Call-indirect caching: protect against out-of-bounds table index during prescan.

Call-indirect caching req

Call-indirect caching: protect against out-of-bounds table index during prescan. (#8541)

* Call-indirect caching: protect against out-of-bounds table index during prescan.

Call-indirect caching requires a "prescan" of a module's code section
during compilation in order to know which tables are possibly written,
and to count call-indirect callsites so that each separate function
compilation can enable caching if possible and use the right slot
range.

This prescan is not integrated with the usual validation logic (nor
should it be, probably, for performance), so it's possible that an
out-of-bounds table index or other illegal instruction could be
present. We previously indexed into an internal data
structure (`table_plans`) with this index, allowing for a compilation
panic on certain invalid modules before validation would have caught
it. This PR fixes that with a one-off check at the single point that
we interpret a parameter (the table index) from an instruction during
the prescan.

* Add test case.

show more ...

Fix combining `cache_call_indirects` and memory64 (#8544)

This commit fixes a fuzz bug that popped up where the
`cache_call_indirects` feature wasn't reading memory64-based offsets
correctly. This i

Fix combining `cache_call_indirects` and memory64 (#8544)

This commit fixes a fuzz bug that popped up where the
`cache_call_indirects` feature wasn't reading memory64-based offsets
correctly. This is due to (not great) API design in `wasmparser`
(introduced by me) where wasmparser by default won't read 64-bit offsets
unless explicitly allowed to. This is to handle how spec tests assert
that overlong 32-bit encodings are invalid as the memory64 proposal
isn't merged into the spec yet.

The fix here is to call `allow_memarg64` with whether memory64 is
enabled or not and then that'll enable reading these overlong and/or
larger offsets correctly.

show more ...

Slightly improve error message of feeding components to `Module` APIs (#8235)

This commit slightly improves the error message of feeding a component
into a module-taking API. This at least tries to

Slightly improve error message of feeding components to `Module` APIs (#8235)

This commit slightly improves the error message of feeding a component
into a module-taking API. This at least tries to convey that a component
was recognized but a module was expected.

show more ...

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usag

Update some CI dependencies (#7983)

* Update some CI dependencies

* Update to the latest nightly toolchain
* Update mdbook
* Update QEMU for cross-compiled testing
* Update `cargo nextest` for usage with MIRI

prtest:full

* Remove lots of unnecessary imports

* Downgrade qemu as 8.2.1 seems to segfault

* Remove more imports

* Remove unused winch trait method

* Fix warnings about unused trait methods

* More unused imports

* More unused imports

show more ...

Enable threads, multi-memory, and relaxed-simd by default (#7285)

* Enable threads, multi-memory, and relaxed-simd by default

This commit enables by default three proposals that were advanced to
st

Enable threads, multi-memory, and relaxed-simd by default (#7285)

* Enable threads, multi-memory, and relaxed-simd by default

This commit enables by default three proposals that were advanced to
stage 4 in the proposal process at last week's in-person CG meeting.
These proposals are:

* `threads` - atomic instructions and shared memory
* `multi-memory` - the ability to have more than one linear memory
* `relaxed-simd` - new simd instructions that may differ across
platforms

These proposals are now all enabled by default in Wasmtime. Note that
they can still be selectively disabled via `Config` options.

* Fix an x64-specific test

show more ...

Remove recursion from AMode lowering rules (#6968)

* x64: Remove recursion in `to_amode` helper

This commit removes the recursion present in the x64 backend's
`to_amode` and `to_amode_add` helpers.

Remove recursion from AMode lowering rules (#6968)

* x64: Remove recursion in `to_amode` helper

This commit removes the recursion present in the x64 backend's
`to_amode` and `to_amode_add` helpers. The recursion is currently
unbounded and controlled by user input meaning it's not too hard to
craft user input which triggers stack overflow in the host. By removing
recursion there's no need to worry about this since the stack depth will
never be hit.

The main concern with removing recursion is that code quality may not be
quite as good any more. The purpose of the recursion here is to "hunt
for constants" and update the immediate `Offset32`, and now without
recursion only at most one constant is found and folded instead of an
arbitrary number of constants as before. This should continue to produce
the same code as before so long as optimizations are enabled, but
without optimizations this will produce worse code than before.

Note with a hypothetical mid-end optimization that does this constant
folding for us the rules here could be further simplified to purely
consider the shape of the input `Value` to amode computation without
considering constants at all.

* aarch64: Remove recursion from amode lowering rules

Same as the prior commit for x64, but for aarch64 instead. Unlikely to
be reachable from wasm due to this only being a part of addressing modes
which are more strictly controlled in wasm (e.g. wasm addresses are
always a zero-extended value added to a base, so it's not possible to
have a long chain of constants at the top level in clif)

show more ...

Update wasm-tools dependencies (#6739)

Brings in a few minor updates and some minor fixes for compliance with
the latest spec test suite (updating that is deferred to a separate PR
though).

Run some tests in MIRI on CI (#6332)

* Run some tests in MIRI on CI

This commit is an implementation of getting at least chunks of Wasmtime
to run in MIRI on CI. The full test suite is not possible

Run some tests in MIRI on CI (#6332)

* Run some tests in MIRI on CI

This commit is an implementation of getting at least chunks of Wasmtime
to run in MIRI on CI. The full test suite is not possible to run in MIRI
because MIRI cannot run Cranelift-produced code at runtime (aka it
doesn't support JITs). Running MIRI, however, is still quite valuable if
we can manage it because it would have trivially detected
GHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of this
PR is to select a subset of the test suite to execute in CI under MIRI
and boost our confidence in the copious amount of `unsafe` code in
Wasmtime's runtime.

Under MIRI's default settings, which is to use the [Stacked
Borrows][stacked] model, much of the code in `Instance` and `VMContext`
is considered invalid. Under the optional [Tree Borrows][tree] model,
however, this same code is accepted. After some [extremely helpful
discussion][discuss] on the Rust Zulip my current conclusion is that
what we're doing is not fundamentally un-sound but we need to model it
in a different way. This PR, however, uses the Tree Borrows model for
MIRI to get something onto CI sooner rather than later, and I hope to
follow this up with something that passed Stacked Borrows. Additionally
that'll hopefully make this diff smaller and easier to digest.

Given all that, the end result of this PR is to get 131 separate unit
tests executing on CI. These unit tests largely exercise the embedding
API where wasm function compilation is not involved. Some tests compile
wasm functions but don't run them, but compiling wasm through Cranelift
in MIRI is so slow that it doesn't seem worth it at this time. This does
mean that there's a pretty big hole in MIRI's test coverage, but that's
to be expected as we're a JIT compiler after all.

To get tests working in MIRI this PR uses a number of strategies:

* When platform-specific code is involved there's now `#[cfg(miri)]` for
MIRI's version. For example there's a custom-built "mmap" just for
MIRI now. Many of these are simple noops, some are `unimplemented!()`
as they shouldn't be reached, and some are slightly nontrivial
implementations such as mmaps and trap handling (for native-to-native
function calls).

* Many test modules are simply excluded via `#![cfg(not(miri))]` at the
top of the file. This excludes the entire module's worth of tests from
MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to
ignore tests by default on MIRI. The latter form is used in modules
where some tests work and some don't. This means that all future test
additions will need to be effectively annotated whether they work in
MIRI or not. My hope though is that there's enough precedent in the
test suite of what to do to not cause too much burden.

* A number of locations are fixed with respect to MIRI's analysis. For
example `ComponentInstance`, the component equivalent of
`wasmtime_runtime::Instance`, was actually left out from the fix for
the CVE by accident. MIRI dutifully highlighted the issues here and
I've fixed them locally. Some locations fixed for MIRI are changed to
something that looks similar but is subtly different. For example
retaining items in a `Store<T>` is now done with a Wasmtime-specific
`StoreBox<T>` type. This is because, with MIRI's analyses, moving a
`Box<T>` invalidates all pointers derived from this `Box<T>`. We don't
want these semantics, so we effectively have a custom `Box<T>` to suit
our needs in this regard.

* Some default configuration is different under MIRI. For example most
linear memories are dynamic with no guards and no space reserved for
growth. Settings such as parallel compilation are disabled. These are
applied to make MIRI "work by default" in more places ideally. Some
tests which perform N iterations of something perform fewer iterations
on MIRI to not take quite so long.

This PR is not intended to be a one-and-done-we-never-look-at-it-again
kind of thing. Instead this is intended to lay the groundwork to
continuously run MIRI in CI to catch any soundness issues. This feels,
to me, overdue given the amount of `unsafe` code inside of Wasmtime. My
hope is that over time we can figure out how to run Wasm in MIRI but
that may take quite some time. Regardless this will be adding nontrivial
maintenance work to contributors to Wasmtime. MIRI will be run on CI for
merges, MIRI will have test failures when everything else passes,
MIRI's errors will need to be deciphered by those who have probably
never run MIRI before, things like that. Despite all this to me it seems
worth the cost at this time. Just getting this running caught two
possible soundness bugs in the component implementation that could have
had a real-world impact in the future!

[stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md
[tree]: https://perso.crans.org/vanille/treebor/
[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question

* Update alignment comment

show more ...

Fix libcall relocations for precompiled modules (#5608)

* Fix libcall relocations for precompiled modules

This commit fixes some asserts and support for relocation libcalls in
precompiled module

Fix libcall relocations for precompiled modules (#5608)

* Fix libcall relocations for precompiled modules

This commit fixes some asserts and support for relocation libcalls in
precompiled modules loaded from disk. In doing so this reworks how mmaps
are managed for files from disk. All non-file-backed `Mmap` entries are
read/write but file-backed versions were readonly. This commit changes
this such that all `Mmap` objects, even if they're file-backed, start as
read/write. The file-based versions all use copy-on-write to preserve
the private-ness of the mapping.

This is not functionally intended to change anything. Instead this
should have some more memory writable after a module is loaded but the
text section, for example, is still left as read/execute when loading is
finished. Additionally this makes modules compiled in memory more
consistent with modules loaded from disk.

* Update a comment

* Force images to become readonly during publish

This marks compiled images as entirely readonly during the
`CodeMemory::publish` step which happens just before the text section
becomes executable. This ensures that all images, no matter where they
come from, are guaranteed frozen before they start executing.

show more ...