Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Wasi]Wasm export functions with name space cannot be invoked correctly #106310

Closed
ReneeGA2020 opened this issue Aug 13, 2024 · 10 comments · Fixed by #106632
Closed

[Wasi]Wasm export functions with name space cannot be invoked correctly #106310

ReneeGA2020 opened this issue Aug 13, 2024 · 10 comments · Fixed by #106632
Assignees
Labels
arch-wasm WebAssembly architecture area-Interop-mono in-pr There is an active PR which will close this issue when it is merged os-wasi Related to WASI variant of arch-wasm
Milestone

Comments

@ReneeGA2020
Copy link

ReneeGA2020 commented Aug 13, 2024

Description

If I put a wasm export function into a name space, it allows me to build, but it cannot be invoked correctly.

Reproduction Steps

Let‘s’ take the native interop sample as example: https://github.com/dotnet/runtime/tree/main/src/mono/sample/wasi/native

This works and can be successfully invoked by outside code via name 'ManagedFunc'.

    public static class A
    {

        [UnmanagedCallersOnly(EntryPoint = "ManagedFunc")]
        public static int MyExport(int number)
        {
            // called from MyImport aka UnmanagedFunc
            Console.WriteLine($"MyExport({number}) -> 42");
            return 42;
        }
    }

but if I give it a namespace, then run the code, wasmtime gave me an error.

namespace ATest
    public static class A
    {

        [UnmanagedCallersOnly(EntryPoint = "ManagedFunc")]
        public static int MyExport(int number)
        {
            // called from MyImport aka UnmanagedFunc
            Console.WriteLine($"MyExport({number}) -> 42");
            return 42;
        }
    }
}

Expected behavior

The code run correctly.

Actual behavior

Error: failed to run main module dotnet.wasm

Caused by:
0: failed to invoke command default
1: error while executing at wasm backtrace:
0: 0x2884e1 - dotnet.wasm!abort
1: 0x28a2b5 - dotnet.wasm!__assert_fail
2: 0x8230 - mono_wasm_marshal_get_managed_wrapper
at C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.wasi-wasm\9.0.0-preview.6.24327.7\runtimes\wasi-wasm\native\src\runtime.c:380:2
3: 0x69e2 - ManagedFunc
at E:/Source/Repos/EventTest/EventTest/E:/source/repos/EventTest/EventTest/obj/Debug/net9.0/wasi-wasm/wasm/for-build/pinvoke-table.h:470:4
4: 0x283c44 - UnmanagedFunc
at E:/Source/Repos/EventTest/EventTest/local.c:9:11
5: 0x1e96e - do_icall
at /__w/1/s/src/mono/mono/mini/interp/interp.c:2356:10
6: 0x1d316 - do_icall_wrapper
at /__w/1/s/src/mono/mono/mini/interp/interp.c:2466:3
7: 0xd463 - mono_interp_exec_method
at /__w/1/s/src/mono/mono/mini/interp/interp.c:4226:4
8: 0xc0ef - interp_runtime_invoke
at /__w/1/s/src/mono/mono/mini/interp/interp.c:2215:2
9: 0x135c9f - mono_jit_runtime_invoke
at /__w/1/s/src/mono/mono/mini/mini-runtime.c:3485:10
10: 0xf353e - do_runtime_invoke
at /__w/1/s/src/mono/mono/metadata/object.c:2572:11
11: 0xf3fac - mono_runtime_try_invoke
at /__w/1/s/src/mono/mono/metadata/object.c:2729:9
12: 0xf88d8 - do_try_exec_main
at /__w/1/s/src/mono/mono/metadata/object.c:4753:3
13: 0xf8343 - mono_runtime_try_exec_main
at /__w/1/s/src/mono/mono/metadata/object.c:4821:9 - mono_runtime_run_main
at /__w/1/s/src/mono/mono/metadata/object.c:4343:9
14: 0xa99a - __main_argc_argv
at C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.wasi-wasm\9.0.0-preview.6.24327.7\runtimes\wasi-wasm\native\src\main.c:107:12
15: 0x288085 - dotnet.wasm!__main_void
16: 0x6312 - dotnet.wasm!_start
2: wasm trap: wasm unreachable instruction executed

Regression?

No response

Known Workarounds

Don't put export functions into a namespace

Configuration

No response

Other information

Now, I'm not quite sure if it's a feature or a bug.
Perhaps wasm export functions with namespace actually works, and I just need to change the way the local.c file invoke them? I missed a prefix somehow?

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 13, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Aug 13, 2024
@vcsjones vcsjones added area-System.Runtime.InteropServices.JavaScript and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 13, 2024
@ReneeGA2020 ReneeGA2020 changed the title Wasm export functions with name space cannot be invoked correctly? [Wasi]Wasm export functions with name space cannot be invoked correctly Aug 14, 2024
@ReneeGA2020
Copy link
Author

I guess this is not much of area JS interop, as it's more of a wasi interprop issue... Changed the title to
include a [wasi] tag.

It looks like the generated pinvoke table does not have correct a namespace parameter, as the namespace was conjoined into the type parameter.

@lewing
Copy link
Member

lewing commented Aug 14, 2024

@mkhamoyan when the entry point is defined we need to use it without the namespace, lets discuss

@lewing lewing added this to the 9.0.0 milestone Aug 14, 2024
@lewing lewing added arch-wasm WebAssembly architecture and removed untriaged New issue has not been triaged by the area owner labels Aug 14, 2024
Copy link
Contributor

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

@pavelsavara
Copy link
Member

pavelsavara commented Aug 19, 2024

What changed recently is that I enabled <TrimMode>full</TrimMode> for WASI.
Which for some reason trims also UnmanagedCallersOnly methods.

If I add ILLink.Descriptors.xml to protect the method the sample works fine.

After that namespace change works well for me too.

@pavelsavara pavelsavara assigned pavelsavara and unassigned mkhamoyan Aug 19, 2024
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Aug 19, 2024
@pavelsavara pavelsavara modified the milestones: 9.0.0, 10.0.0 Aug 21, 2024
@ReneeGA2020
Copy link
Author

ReneeGA2020 commented Aug 21, 2024

What changed recently is that I enabled <TrimMode>full</TrimMode> for WASI. Which for some reason trims also UnmanagedCallersOnly methods.

If I add ILLink.Descriptors.xml to protect the method the sample works fine.

After that namespace change works well for me too.

Thanks for the information, <TrimMode>partial</TrimMode> works for me most of the time. Sometimes the generated appbundle folder does not have a icudt.dat file, which cased execution fail.

I copy icudt.dat from other appbundle to the ones that miss the file, and it seems work fine. But I'm not sure if it's the correct workarounds?

Also may I ask an additional question? I guess the wasi C# still does not support any kind of break point debug, does it? Will such a support be planned in the future?

@pavelsavara
Copy link
Member

Sometimes the generated appbundle folder does not have a icudt.dat file, which cased execution fail.

Separate issue for that, steps to reproduce and binlog would help.

Also may I ask an additional question? I guess the wasi C# still does not support any kind of break point debug, does it? Will such a support be planned in the future?

WASI is very immature, unsupported experiment for us at the moment. There are many gaps and this is one of them. We had moment where C# debugging worked, but currently sockets need to be fixed.

@lewing
Copy link
Member

lewing commented Aug 23, 2024

Sometimes the generated appbundle folder does not have a icudt.dat file, which cased execution fail.

Separate issue for that, steps to reproduce and binlog would help.

This might be a problem with the incremental build if you just changed InvariantGlobalization between builds?

@enghch
Copy link

enghch commented Sep 23, 2024

@pavelsavara @lewing I apologize for hijacking this conversation. Can you point me to where I might ask about getting SkiaSharp (which includes a native libskiasharp library) working in a Wasi Console app? It compiles just fine, but at runtime complains with a DllNotFoundException for the native library. I tried adding the Skia.NativeAssets.WebAssembly package, but I don't think it has targets for Wasi wasm.

@lewing
Copy link
Member

lewing commented Sep 24, 2024

@pavelsavara @lewing I apologize for hijacking this conversation. Can you point me to where I might ask about getting SkiaSharp (which includes a native libskiasharp library) working in a Wasi Console app? It compiles just fine, but at runtime complains with a DllNotFoundException for the native library. I tried adding the Skia.NativeAssets.WebAssembly package, but I don't think it has targets for Wasi wasm.

that is something we should discuss at https://github.com/mono/SkiaSharp/issues

@enghch
Copy link

enghch commented Sep 24, 2024

@pavelsavara @lewing OK! I created this issue over there: mono/SkiaSharp#3015

@github-actions github-actions bot locked and limited conversation to collaborators Oct 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Interop-mono in-pr There is an active PR which will close this issue when it is merged os-wasi Related to WASI variant of arch-wasm
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants