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
On Wed, Oct 2, 2024 at 5:33 AM Jakob Kummerow <jkumme...@chromium.org>
wrote:
> 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 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+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
> <https://groups.google.com/d/msgid/v8-users/CAKSzg3TP9_6dWLD-NzORLh7P%2B43vLzOd97X_iRavMRNDpkA%2BNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
--
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/CAPAcDL-w-p9v-39fCU0bsLK6NHkJ%2BpSRqrRtqyvR-T_%2Bn7QcGw%40mail.gmail.com.
