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
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 <[email protected]>
>> 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
[email protected]
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/82ccfa13-5eec-4890-a37e-a158c7afed28n%40googlegroups.com.
