Support for stringref in libwee8

[Alex Dovzhanyn]

Hello all, I am wondering if there is support for WASM stringrefs in libwee8? And if so, it that behind a flag during the build? I am noticing that I'm able to call:

      auto wasmModule = wasm::Module::make(store.get(), binary);

with no issues when I'm not using stringrefs, but as soon as I add a 
      (table $stringrefs 100 stringref)

into the module, the wasm::Module::make seems to fail.

Any pointers would be greatly appreciated! Thanks in advance.

Best,
Alex

[Jakob Kummerow]

Generally speaking, libwee8 supports whatever V8 supports.

That said, the state of the stringref implementation in V8 is that (like all early-stage proposals) it's behind an off-by-default flag: --experimental-wasm-stringref, and libwee8 doesn't have a way to enable such flags at runtime.

If you build your own libwee8, you can hack it by moving the "stringref" entry in src/wasm/wasm-feature-flags.h from the STAGING list to the SHIPPED list below it.

If you don't want to or can't modify libwee8's sources but you do know that you're always linking against libwee8 (and not some other engine's implementation of the Wasm C API), then I think you can use the regular V8 API to call v8::V8::SetFlagsFromString("--experimental-wasm-stringref") early in your startup sequence (before calling the Wasm C API's Engine::make()).

All of that is admittedly far from perfect.

Please also keep in mind that the stringref proposal is currently not on track towards finding community consensus. While we (V8) have no plans to delete our implementation of it, we also cannot make any promises that we will continue to keep it indefinitely if the proposal doesn't advance. At the very least, if/when the proposal does pick up steam again, there will likely be some changes to the behavior of certain features, and when picking those up we will quite likely not worry about backwards compatibility with earlier versions of the proposal. In summary: while I understand that strings are very useful and the stringref proposal would be great to have (especially in non-browser scenarios where the alternative "JS String Builtins" proposal, which the community currently favors, is unavailable), I feel compelled to caution you that basing any larger project on an assumption that stringref will be available is a highly risky decision at this time. On the other hand, if you manage to present a sufficiently compelling use case, you might just be able to influence the community's stance...

--

[Alex Dovzhanyn]

Hi Jakob,

Thanks so much for your highly detailed response! I am building from source so I should be able to change the feature flags, but I'll try setting the v8 flag you mentioned first since that seems to be the less intrusive option.

Thanks for the warning about the stringref proposal! I do understand that it has stagnated as of late and does not look like it will be accepted in its current state. The project that I'm working on is a novelty programming language that compiles to WebAssembly, and the current implementation of strings in the language relies on the stringref proposal for simplicity' sake -- though the plan is to move to a bespoke utf8 implementation once garbage collection is implemented. It would definitely be nice if WebAssembly, as a compilation target, had native support for a string type that doesn't rely on JS string builtins for cases such as this one, where the wasm is not intended to only be run in the browser. But until we reach some sort of consensus on that it looks like we'll just have to roll our own.

Thanks again for your help!

Cheers,

Alex

[Alex Dovzhanyn]

Hello! Following up on this because I am experiencing some unusual behavior when trying to actually use stringrefs after enabling them. So I've enabled stringref by calling v8::V8::SetFlagsFromString("--experimental-wasm-stringref"), which seems to do the trick because now I'm able to compile and run modules that have a stringref table in them. My issue arises when I try to actually use a stringref to do anything. Even a simple hello world function seems to be throwing with an unreachable error.

For example, the following WASM module:

(module
 (type $0 (func (result stringref)))
 (memory $0 1 10)
 (table $ThetaStringRefs 1000 100000000 stringref)
 (export "memory" (memory $0))
 (export "main0" (func $main0))
 (func $main0 (result stringref)
  (string.const "Hello, world!")
 )
)

errors out with the following stacktrace:

==== C stack trace ===============================

    0   CodegenTest                         0x000000010491e643 v8::base::debug::StackTrace::StackTrace() + 19
    1   CodegenTest                         0x00000001049250cb v8::platform::(anonymous namespace)::PrintStackTrace() + 27
    2   CodegenTest                         0x0000000104910e1d V8_Fatal(char const*, ...) + 365
    3   CodegenTest                         0x00000001048fd726 wasm::(anonymous namespace)::FunctionSigToFuncType(v8::internal::Signature<v8::internal::wasm::ValueType> const*) + 838
    4   CodegenTest                         0x00000001048fae9e wasm::(anonymous namespace)::GetImportExportType(v8::internal::wasm::WasmModule const*, v8::internal::wasm::ImportExportKindCode, unsigned int) + 62
    5   CodegenTest                         0x00000001048fb39f wasm::ExportsImpl(v8::internal::Handle<v8::internal::WasmModuleObject>) + 527
    6   CodegenTest                         0x00000001048fb4ed wasm::Module::exports() const + 61
    7   CodegenTest                         0x00000001047077e1 Theta::Runtime::execute(std::__1::vector<char, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 593
    8   CodegenTest                         0x000000010470656b CodeGenTest::setup(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 1531
    9   CodegenTest                         0x00000001046ff5d6 (anonymous namespace)::CATCH2_INTERNAL_TEST_0::test() + 7574
    10  CodegenTest                         0x000000010474b4de Catch::TestInvokerAsMethod<(anonymous namespace)::CATCH2_INTERNAL_TEST_0>::invoke() const + 158
    11  CodegenTest                         0x0000000104827009 Catch::TestCaseHandle::invoke() const + 25
    12  CodegenTest                         0x0000000104826e41 Catch::RunContext::invokeActiveTestCase() + 49
    13  CodegenTest                         0x0000000104824c79 Catch::RunContext::runCurrentTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 1129
    14  CodegenTest                         0x0000000104823f88 Catch::RunContext::runTest(Catch::TestCaseHandle const&) + 632
    15  CodegenTest                         0x000000010480f025 Catch::(anonymous namespace)::TestGroup::execute() + 181
    16  CodegenTest                         0x000000010480e106 Catch::Session::runInternal() + 1062
    17  CodegenTest                         0x000000010480dc77 Catch::Session::run() + 87
    18  CodegenTest                         0x00000001048203ca int Catch::Session::run<char>(int, char const* const*) + 90
    19  CodegenTest                         0x000000010482030f main + 63
    20  dyld                                0x0000000207ffe52e start + 462
    21  dyld                                0x0000000207ff9000 dyld + 0
Trace/BPT trap: 5


It seems that v8 is having some issue with creating the exports for this function that has a stringref as its return type.

Any pointers would be greatly appreciated.

Cheers,
Alex

[Jakob Kummerow]

On Wed, Oct 2, 2024 at 5:49 AM Alex Dovzhanyn <dovzhan...@gmail.com> wrote:

Hello! Following up on this because I am experiencing some unusual behavior when trying to actually use stringrefs after enabling them. So I've enabled stringref by calling v8::V8::SetFlagsFromString("--experimental-wasm-stringref"), which seems to do the trick because now I'm able to compile and run modules that have a stringref table in them. My issue arises when I try to actually use a stringref to do anything.

It's not so much doing "anything" that's the issue, but rather specifically using stringref in the signature of an exported or imported function. That's not implemented, and as such is right to fail.

V8 implements the upstream wasm-c-api as of revision 6db391ee7121a0695602945d11001ea3e00b0afb, dated 2019. That was before newer proposals such as stringref, WasmGC, SIMD, exnref, so the API doesn't know anything about the types introduced by these proposals. As long as those types only show up inside the Wasm module, that shouldn't matter, but you won't be able to use them at the boundary (exported and imported functions, Globals, Tables). I'm aware that this is a severe limitation.

If you wanted to make progress on this front, the first step would be to update the wasm-c-api to support the newer proposals. Some of them are likely straightforward, some might require some nontrivial design work, I'm not sure. I'm also not sure whether an attempt to add support for stringref in particular might encounter resistance, given the state of that proposal.

The second step would then be to update V8's (and, ideally, other engines') implementation to reflect this updated API.

FWIW, I'm not aware of anyone currently working or planning to work on either of these steps.

In the meantime, the following should work:

 (func $main0 (export "main0") (result i32)
  (string.measure_utf8 (string.const "Hello, world!"))

 )

[Alex Dovzhanyn]

Thanks Jakob! Looks like we'll have to implement our own utf8 strings sooner than we planned, as we need a way to access the resulting value of the stringref.

I appreciate the detailed response!

Cheers,
Alex

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/WPFivlQ7Oao/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKSzg3TP9_6dWLD-NzORLh7P%2B43vLzOd97X_iRavMRNDpkA%2BNQ%40mail.gmail.com.