Stream: general

Topic: Upgrading to wasmtime 0.29

Steve Williams (Sep 10 2021 at 07:15):

Hey guys. been a while. Upgrading our wasmtime interface (Windows, Visual Studio C/C++)

Got this : https://pastebin.com/pWJA8sRU

VS2019 : cannot convert argument 2 from 'wasm_val_t [3]' to 'const wasm_val_vec_t *

I just cast it or there's something more fundamental that's changed ? Can't immediately spot a wasm_func_call example, latest API.

Thanks for any assistance.

Steve Williams (Sep 10 2021 at 07:17):

Upgrading to 0.29 as that's latest posted release.

Steve Williams (Sep 10 2021 at 07:25):

nvm, I got it. need to patch as follows :

wasm_val_vec_t _in = WASM_ARRAY_VEC(in);
wasm_val_vec_t _out = WASM_ARRAY_VEC(&out);

if (wasm_func_call(m_assembly.m_init_fn, &_in, &_out))

Steve Williams (Sep 10 2021 at 07:31):

thanks once again for all the hard work on this. might get debugger up & running this time around :)

Steve Williams (Sep 10 2021 at 07:35):

might be wrong but quick inspect looks like extra indirection per function call. hence perf penalty. assume was necessary for some reason.

Steve Williams (Sep 10 2021 at 07:44):

seems reason is to attempt to catch API misuse by trusted code. not sure that's optimal. trusted code should be correct. overhead every call because someone somewhere can't write correct trusted code isn't perhaps the way. my 2c on that.

Steve Williams (Sep 10 2021 at 07:52):

I'd have stuff like that in asserts or debug only path somehow.

Steve Williams (Sep 10 2021 at 08:38):

All for diagnostics to spot coding errors, but they should be behind macros so they're disabled in final release build.

Steve Williams (Sep 10 2021 at 09:13):

& needed another macro as WASM_ARRAY_VEC doesn't calc correctly if there's a single non-array entry. (size 0 incorrectly determined)

// For single element entries.
#define WASM_VEC(x) { 1, &(x) }

Steve Williams (Sep 10 2021 at 09:14):

our stuff running 0.29 now - yay :)

Steve Williams (Sep 10 2021 at 09:14):

happy to post above wherever wasm API issues are tracked if it passes group sanity check as this isn't wasmtime specific.

Steve Williams (Sep 10 2021 at 09:52):

so fast path would just pass wasm_val_vec_t -> data effectively reverting to previous implementation.

Steve Williams (Sep 10 2021 at 16:30):

Above can wait unless anyone sees urgency. Had another look at debugging. Still fails for me :(
Tried reproducting this : YouTube - Debugging WebAssembly with LLDB
On windows, using llvm 12.01 wasmtime 0.29 cargo/rustc latest, the breakpoint isn't hit.

Steve Williams (Sep 10 2021 at 16:32):

Project files here : http://advance-software.com/misc/fizzbuzz.zip

2 binaries in there - wasmtime & python36 - replace with your own to ensure secure test.

Steve Williams (Sep 10 2021 at 16:34):

Can anyone reproduce that debug example on windows plz :)
Discussion with Yuri from ages ago here - updated.
https://github.com/bytecodealliance/wasmtime/issues/1850
Seems to work for him but not for me.
Wanting basic command line reproducing example before experimenting further with VSCode.

Steve Williams (Sep 10 2021 at 16:35):

Could be I have the Cargo.toml wrong - I'm not a rust guy so could be something obviously stupid there. I guessed at it.

Steve Williams (Sep 10 2021 at 16:35):

thanks in advance for any assistance. gave up on debugging last time I tried, but to move to production, we need this working.

Steve Williams (Sep 10 2021 at 16:42):

Is Yuri still the goto guy on this ? I know there have been some changes, but haven't kept up as have been busy with other stuff.

Steve Williams (Sep 10 2021 at 16:49):

.

Steve Williams (Sep 10 2021 at 17:42):

connected with yuri on mozilla/matrix thingy/web assembly group

Steve Williams (Sep 10 2021 at 18:23):

tested fizzbuzz debugging example linux (ubuntu) with llvm 10 installed. works. so have a sane project config & its platform issue of some kind.

Steve Williams (Sep 10 2021 at 18:32):

tested llvm 10 windows - same version that worked under linux. no joy so a bug of some kind. yuri said windows implementation was a bit flaky so fun times ahead fixing that.

Steve Williams (Sep 10 2021 at 18:40):

Updated : advance-software.com/misc/fizzbuzz.zip

bug_report.txt in there provides repro steps & files required to reproduce.

Steve Williams (Sep 10 2021 at 18:41):

happy to do what I can to help get this resolved as should make a contribution if I'm using this too & if its a windows issue, I'm as well placed as anyone to figure it out. that said, input welcome - debuggers scare me :)

Steve Williams (Sep 10 2021 at 19:09):

& over here : https://discord.com/channels/636084430946959380/636732809708306432

fun times :)

Steve Williams (Sep 10 2021 at 19:37):

https://lldb.llvm.org/status/status.html

says JIT not implemented Windows yet - so that'd explain it :)

however docs could be out of date.

Steve Williams (Sep 10 2021 at 19:43):

... but this says it does work, so I'm confused.

https://lists.llvm.org/pipermail/lldb-dev/2015-December/009003.html

Steve Williams (Sep 10 2021 at 19:47):

& lli tool referenced is nowhere to be seen.

Steve Williams (Sep 10 2021 at 20:04):

https://reviews.llvm.org/D15172

appears to be a 1 line change that if I'm following claims to fix it.

I'll roll my own lldb tomorrow if still required. gonna debug a debugger :)

Steve Williams (Sep 11 2021 at 09:09):

Bulding llvm trunk. This gets fixed.

Steve Williams (Sep 11 2021 at 09:31):

llvm building from a vs2019 x64 prompt as per build instructions here.
https://github.com/llvm/llvm-project
tried from a mozilla-build prompt - no joy but that's not essential.

Steve Williams (Sep 13 2021 at 09:48):

update: need to perform "ninja" (as well as subprojects clang & lldb) in build dir to create all dependencies required to run lldb jit/gdb test which is failing for me. its a monster - 140GB required for full debug build of required dependencies. current status on discord.

Last updated: Dec 23 2024 at 12:05 UTC