Allocate failed？

[orangeC23]

Test Case

The rust file is :

use std::fs::File;
use std::os::fd::AsRawFd;

fn main() {
    let file = File::open("Data/hello.txt").expect("Can not open.");
    let file_descriptor = file.as_raw_fd();
    println!("File descriptor {}", file_descriptor);

    unsafe{
        let p1:wasi::Fd = file_descriptor as u32; 
        let p2:wasi::Filesize = 0;
        let p3:wasi::Filesize = 200;

        println!("{:?}", wasi::fd_allocate(p1, p2, p3).unwrap());
    }
}

Steps to Reproduce

1. Use cargo build --target wasm32-wasi to compile the rust file into WASM binaries allocate.wasm.
2. Use command ls -al in directory Data: -rw-r--r-- 1 staff 100 7 8 17:03 hello.txt
3. execute command wasmer run --dir=Data allocate.wasm wasmer successfully execute the WASM binaries and use command ls -al in directory Data: -rw-r--r-- 1 staff 200 7 8 17:05 hello.txt
4. execute command iwasm --dir=Data allocate.wasm WAMR print:

   File descriptor 4
   thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Errno { code: 52, name: "NOSYS", message: "Function not supported." }', src/main.rs:14:56
   note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
   Exception: unreachable

Thus, WAMR failed to allocate. However, wasmer executed successfully and allocate the size of hello.txt from 100 to 200.

[TianlongLiang]

In order to use WASI LIBC APIs in WAMR, you will need to use this CMake flag when compiling:

# in directory: product-mini/platforms/linux
cmake -DWAMR_BUILD_LIBC_WASI=1 -B build
cmake --build build

This will solve the error "Function not supported." However, I see you use a native file descriptor directly, not a WASI file descriptor. And you are using WASI API fd_allocate with that native descriptor. That might be a problem as well

[orangeC23]

Could you please offer more information about how to using fd_allocate with a WASI file descriptor ? Thanks a lot !

[orangeC23]

However, using the compiling method you provided, the error stiil occurs:

~/WASM/engines/WAMR/version1.2.2/wasm-micro-runtime/product-mini/platforms/darwin/build/iwasm --dir=Data fd_allocate.wasm
File descriptor 10
Err(Errno { code: 52, name: "NOSYS", message: "Function not supported." }

[TianlongLiang]

> cmake -DWAMR_BUILD_LIBC_WASI=1 -B build
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build Configurations:
     Build as target X86_64
     CMAKE_BUILD_TYPE Release
     WAMR Interpreter enabled
     WAMR AOT enabled
     WAMR Fast JIT disabled
     WAMR LLVM ORC JIT disabled
     Libc builtin enabled
     Libc WASI enabled
     Fast interpreter enabled
     Multiple modules disabled
     Bulk memory feature enabled
     SIMD enabled
     Reference types disabled
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Configuring done (0.4s)
-- Generating done (0.0s)

Can you check whether your CMake configuration stage output Libc WASI enabled?

Could you please offer more information about how to using fd_allocate with a WASI file descriptor ? Thanks a lot !

You can check the Rust WASI API document for how to obtain a WASI file descriptor. Normally, you don't need to use WASI Libc APIs directly, since when you compile such a program to WebAssembly, the compiler, and the WASI SDK handle the task of mapping system library calls to the corresponding WASI Libc APIs. So it's totally fine and even it's more portable to use system's standard library.

In your case, I can see why you want to use fd_allocate for there is no one simple equivalent API in Rust if I remember correctly. But I guess the effort of writing a "WASI Libc" version file open isn't that easy too……I think maybe it's easier to find the workaround using std library API.

[orangeC23]

> cmake -DWAMR_BUILD_LIBC_WASI=1 -B build
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build Configurations:
     Build as target X86_64
     CMAKE_BUILD_TYPE Release
     WAMR Interpreter enabled
     WAMR AOT enabled
     WAMR Fast JIT disabled
     WAMR LLVM ORC JIT disabled
     Libc builtin enabled
     Libc WASI enabled
     Fast interpreter enabled
     Multiple modules disabled
     Bulk memory feature enabled
     SIMD enabled
     Reference types disabled
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Configuring done (0.4s)
-- Generating done (0.0s)

Can you check whether your CMake configuration stage output Libc WASI enabled?

Could you please offer more information about how to using fd_allocate with a WASI file descriptor ? Thanks a lot !

You can check the Rust WASI API document for how to obtain a WASI file descriptor. Normally, you don't need to use WASI Libc APIs directly, since when you compile such a program to WebAssembly, the compiler, and the WASI SDK handle the task of mapping system library calls to the corresponding WASI Libc APIs. So it's totally fine and even it's more portable to use system's standard library.

In your case, I can see why you want to use fd_allocate for there is no one simple equivalent API in Rust if I remember correctly. But I guess the effort of writing a "WASI Libc" version file open isn't that easy too……I think maybe it's easier to find the workaround using std library API.

Thanks a lot ! yes, it prints:

-- The C compiler identification is AppleClang 14.0.3.14030022
-- The CXX compiler identification is AppleClang 14.0.3.14030022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build Configurations:
     Build as target X86_64
     CMAKE_BUILD_TYPE Release
     WAMR Interpreter enabled
     WAMR AOT enabled
     WAMR Fast JIT disabled
     WAMR LLVM ORC JIT disabled
     Libc builtin enabled
     Libc WASI enabled
     Fast interpreter enabled
     Multiple modules disabled
     Bulk memory feature enabled
     SIMD enabled
     Reference types disabled
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/orange/wasm-micro-runtime/product-mini/platforms/darwin/build

[TianlongLiang]

Can you try using uvwasi instead:

cmake -DWAMR_BUILD_LIBC_UVWASI=1 -B build
cmake --build build

"Function not supported." Might be a platform issue, are you using M1/M2 Mac?

[orangeC23]

> cmake -DWAMR_BUILD_LIBC_WASI=1 -B build
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build Configurations:
     Build as target X86_64
     CMAKE_BUILD_TYPE Release
     WAMR Interpreter enabled
     WAMR AOT enabled
     WAMR Fast JIT disabled
     WAMR LLVM ORC JIT disabled
     Libc builtin enabled
     Libc WASI enabled
     Fast interpreter enabled
     Multiple modules disabled
     Bulk memory feature enabled
     SIMD enabled
     Reference types disabled
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Configuring done (0.4s)
-- Generating done (0.0s)

Can you check whether your CMake configuration stage output Libc WASI enabled?

Could you please offer more information about how to using fd_allocate with a WASI file descriptor ? Thanks a lot !

You can check the Rust WASI API document for how to obtain a WASI file descriptor. Normally, you don't need to use WASI Libc APIs directly, since when you compile such a program to WebAssembly, the compiler, and the WASI SDK handle the task of mapping system library calls to the corresponding WASI Libc APIs. So it's totally fine and even it's more portable to use system's standard library. In your case, I can see why you want to use fd_allocate for there is no one simple equivalent API in Rust if I remember correctly. But I guess the effort of writing a "WASI Libc" version file open isn't that easy too……I think maybe it's easier to find the workaround using std library API.

Thanks a lot ! yes, it prints:

-- The C compiler identification is AppleClang 14.0.3.14030022
-- The CXX compiler identification is AppleClang 14.0.3.14030022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build Configurations:
     Build as target X86_64
     CMAKE_BUILD_TYPE Release
     WAMR Interpreter enabled
     WAMR AOT enabled
     WAMR Fast JIT disabled
     WAMR LLVM ORC JIT disabled
     Libc builtin enabled
     Libc WASI enabled
     Fast interpreter enabled
     Multiple modules disabled
     Bulk memory feature enabled
     SIMD enabled
     Reference types disabled
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/orange/wasm-micro-runtime/product-mini/platforms/darwin/build

Sorry, one more question. In the Rust WASI API document for how to obtain a WASI file descriptor, there still has a Fd parameter, how to define the Fd parameter when using function path_open?

[TianlongLiang]

I am not sure, I never use the WASI API directly. I can only give you some suggestions. You can write a program using the file open method provided in Rust standard library. Then after compiling it into wasm code, read the source code of that wast program, it should have the process of how to use WASI API to obtain a WASI Fd properly.

[orangeC23]

I am not sure, I never use the WASI API directly. I can only give you some suggestions. You can write a program using the file open method provided in Rust standard library. Then after compiling it into wasm code, read the source code of that wast program, it should have the process of how to use WASI API to obtain a WASI Fd properly.

Thanks a lot !