On Wed, Oct 2, 2024 at 5:49 AM Alex Dovzhanyn <dovzhanyn.a...@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
<https://source.chromium.org/chromium/chromium/src/+/main:v8/third_party/wasm-api/README.v8>
the upstream wasm-c-api as of revision
6db391ee7121a0695602945d11001ea3e00b0afb
<https://github.com/WebAssembly/wasm-c-api/tree/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!"))
)
> 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
> On Friday, September 27, 2024 at 12:12:58 PM UTC-4 Alex Dovzhanyn wrote:
>
>> 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
>>
>> On Friday, September 27, 2024 at 5:56:39 AM UTC-4 Jakob Kummerow wrote:
>>
>>> 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...
>>>
>>>
>>> On Fri, Sep 27, 2024 at 2:05 AM Alex Dovzhanyn <dovzhan...@gmail.com>
>>> wrote:
>>>
>>>> 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
>>>>
>>>> --
>>>
>>>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@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.
