This is the tracking issue for the Branch Hinting proposal.

This is the tracking issue for the Reference types proposal.

This is the tracking issue for the Multi-value proposal.

This is the tracking issue for the Threads proposal.

This is the tracking issue for the Extended Name Section proposal.

A preliminary implementation (temporarily disabled) can be found here

This is the tracking issue for the Compilation Hints proposal.

Hey, thanks for putting this up! I just tried running it, but it seems to be getting stuck on an unhandled exception:

❯ just run-riscv64
...
riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000007, epc:0x000000008020aa2a, tval:0x0001000380ae6000, desc=fault_store
Invalid write at addr 0x1000380AE6000, size 4, region '(null)', reason: rejected
riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000007, epc:0x000000008020aa2a, tval:0x0001000380ae6000, desc=fault_store
Invalid write at addr 0x1000380AE6000, size 4, region '(null)', reason: rejected
...

This is with

❯ cargo --version
cargo 1.81.0-nightly (4ed7bee47 2024-06-25)

❯ qemu-system-riscv64 --version
QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.21)

Looking at the binaries, the faulting address seems to be here:

❯ riscv64-unknown-elf-objdump -d target/riscv64gc-unknown-none-elf/debug/loader

000000008020aa1c <_ZN6loader4arch7riscv649fillstack17hca16c52fb1691861E>:
    8020aa1c:   2b383337                lui     t1,0x2b383
    8020aa20:   030a                    slli    t1,t1,0x2
    8020aa22:   ace30313                addi    t1,t1,-1330 # 2b382ace <$d.168+0x2b20fb28>
    8020aa26:   405102b3                sub     t0,sp,t0
    8020aa2a:   0062a023                sw      t1,0(t0) # 20000 <$d.18+0x2c5>
    8020aa2e:   02a1                    addi    t0,t0,8
    8020aa30:   fe22ede3                bltu    t0,sp,8020aa2a <_ZN6loader4arch7riscv649fillstack17hca16c52fb1691861E+0xe>
    8020aa34:   8082                    ret
        ...

By the way, how is enabling of logging supposed to work? Just by setting the RUST_LOG env variable?

This is the tracking issue for the Relaxed SIMD proposal.

This is the tracking issue for the Typed Function References proposal.

This is the tracking issue for the Relaxed dead code validation proposal.

This is the tracking issue for the Exception handling proposal.

This is the tracking issue for the Garbage collection proposal.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update rust crate clap to v4.5.15
• chore(deps): update rust crate syn to v2.0.73
• fix(deps): update rust crate serde to v1.0.206
• chore(deps): update rust crate wasmparser to 0.215.0
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

We need a proper test harness setup.

This is the tracking issue for the Fixed-width SIMD proposal.

This is the tracking issue for the Extended Constant Expressions proposal.

This is the tracking issue for the Numeric Values in WAT Data Segments proposal.

This is the tracking issue for the Custom Annotation Syntax in the Text Format proposal.

This is the tracking issue for the Instrument and Tracing Technology proposal as well as general guest instrumentation features

The corresponding proposal is not very well fleshed out, but the need for tracing and instrumentation features that allow developers and developer tools to trace back generated machine code to source code, measure execution times etc.

This is the tracking issue for the Constant Time proposal.

Currently all log messages are emitted regardless of level or origin. As cranelift and other dependencies produce lots of messages it would be very helpful to filter which messages are emitted.

Having a similar system to what env_logger does would be very helpful, env vars could be set at compile time or better yet passed to the kernel by the loader.

For reference the current log implementation for the kernel and loader respectively can be found here: https://github.com/JonasKruckenberg/k23/blob/main/kernel/src/logger.rs https://github.com/JonasKruckenberg/k23/blob/main/loader/src/logger.rs

The pci_types crate is likely useful for this. It is used by Redox OS too.

This is the tracking issue for the Multiple memories proposal.

This is the tracking issue for the Custom Page Sizes proposal.

This is the tracking issue for the Memory64 proposal.

Open Questions

• Bounds checks?
• Multiple Memories?

Currently the chosen memory mode for the system is set at compile-time (by all structs being generic over M: vmm::Mode).

Ideally however, we would be able to chose the "right" memory mode based on the CPU feature set. This probably requires removing the generic, making vmm::Mode object-safe and passing it as a &mut dyn vmm::Mode throughout (or a static MODE variable similar to how logs logger works?).

Support for declaring a chosen memory mode is already implemented in the loader_api::LoaderConfig struct, just not utilised yet.

This is the tracking issue for the Tail call proposal.