0xMiden / 0xMiden/compiler

Use `main` entrypoint for note scripts

Aberta
#350 3 comentários 0 reações 1 responsável Reivindicada por @greenhat Ver no GitHub
Linguagem predominante
Rust
Estrelas
115
Forks
84
Merge médio
1d 8h
PRs com merge (30d)
15

Descrição

I compiled this P2ID note script using the `main` entrypoint:

```rust
#![no_std]
#![no_main]

#[global_allocator]
static ALLOC: miden::BumpAlloc = miden::BumpAlloc::new();

#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}

mod bindings;

fn main() {
let inputs = miden::note::get_inputs();
let target_account_id_felt = inputs[0];
let account_id = miden::account::get_id();
assert_eq!(account_id.as_felt(), target_account_id_felt);
let assets = miden::note::get_assets();
for asset in assets {
bindings::miden::basic_wallet::basic_wallet::receive_asset(asset);
}
}

#[no_mangle]
fn __main_void() -> i32 {
main();
0
}

#[no_mangle]
fn __wasm_call_dtors() {}

#[no_mangle]
fn __wasi_proc_exit(_: u32) {}
```

`__*` Rust functions need to be defined to make component encoder happy. Otherwise, it will fail on unknown imports. I presume they are only implemented in `std` environment. The command component is heavy on `wasi:*` code for I/O, files, etc. so I believe `no_std` is not really supported for the command components. We can "hide" those functions in the Miden SDK crate or generate via macros.

The Rust code above compiles to the following Wasm component - https://gist.github.com/greenhat/5ea1e3c0651f717137f778d958b5cbd3

There are two problems with this component:

1. The second core module (`core module (;1;)`) with all `wasi:*` machinery is brought in by the adapter in `cargo-component` at https://github.com/bytecodealliance/cargo-component/blob/37c042e3340c25cfcb3646a2445e46321289bbfe/src/lib.rs#L900-L902 and is built from https://github.com/bytecodealliance/wasmtime/blob/b9874992ba92b06cbbfab7131ef740ba4c10720f/crates/wasi-preview1-component-adapter/src/lib.rs# crate in `wasmtime` repo.
I want to craft our own some sort of "empty" adapter to get rid of the `wasi:*` code.

2. The `_start` function is supposed to be the entrypoint for the command component (used in the second core module):
```wasm
(func $_start (;6;) (type 5)
(local i32)
block ;; label = @1
block ;; label = @2
global.get $GOT.data.internal.__memory_base
i32.const 1048612
i32.add
i32.load
br_if 0 (;@2;)
global.get $GOT.data.internal.__memory_base
i32.const 1048612
i32.add
i32.const 1
i32.store
call $__wasm_call_ctors
call $__main_void
local.set 0
call $__wasm_call_dtors
local.get 0
br_if 1 (;@1;)
return
end
unreachable
unreachable
end
local.get 0
call $__wasi_proc_exit
unreachable
)
```

The Rust code for it is in the `wasi-libc` - https://github.com/WebAssembly/wasi-libc/blob/98897e29fcfc81e2b12e487e4154ac99188330c4/libc-bottom-half/crt/crt1-command.c

With `__wasm_call_ctors` and `__wasm_call_dtors` being empty functions, the only thing that this code is doing is preventing the reentrance of the `_start` function.
We can probably ignore `_start` altogether and call the `__main_void` function directly as our entrypoint.

Guia de contribuição

Abrir o guia de contribuição

Direção de pesquisa

The issue involves modifying the compiler's entrypoint handling for note scripts. Examine the cargo-component adapter code linked in the issue and the wasi-libc crt1-command.c to understand the current _start function. The goal is to create an empty adapter to avoid wasi:* imports and call __main_void directly. Start by looking at the Miden SDK crate structure and the component encoder to see where entrypoints are defined.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
rust, wasm
Domínio
compilers
Tipo de issue
Funcionalidade
Dificuldade
4/5
Tempo estimado
3-5 dias
Status de atividade
Estagnada
Clareza
Razoavelmente clara
Facilidade para iniciantes
30/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.