Only one release from over a year ago.
https://github.com/WebAssembly/wasi-libc
As I'd like a refresh to bring us up to date with this stuff, will have a go at compiling myself, but there should probably be an official update too :)
wasmtime rocking. thanks guys :)
the wasi-sdk repo has releases that include the sysroot, i.e. wasi-libc. E.g. here's wasi-sdk-11, released 4 days ago
ahh, thanks. was looking in the wrong place then :)
It'd be good to have wasi-libc's README point to those releases. I don't have the time to do that right now, but I'd gladly review a PR ;)
I prob wouldn't have read it :)
we're pre-funding so I'm cutting every corner going until we're stable. so please don't mistake my limited engagement for not caring. I do. once rent covered, can breathe again.
my problem, not yours just explaining in crunch mode. light at end of tunnel spotted. this is coming together nicely.
Maybe just replace the text here :
https://github.com/WebAssembly/wasi-libc/releases
... with :
wasi-sdk is now available from :
https://github.com/WebAssembly/wasi-sdk/releases
<><> infinity XSG / web assembly SDK 1.0 has shipped !
http://advance-software.com/develop
wasmtime inside
I found at typo: "Please install latest LLLVM for your operating system of choice."
happy to add a logo, link to credits & anything else you want. no debugger support yet - that's on my todo list.
also happy for this not to be here if its considered inappropriate promo. thought you'd like to see your baby in action.
critique welcome.
thanks :)
typo fixed. good spot.
np
on that, how do I drop debugger in, reminders of what's required welcome. that should probably be next.
/me reviews previous threads regarding debugger support.
@Steve Williams and how is it going?
good, thanks. next step is how to compile with debug info, then how to invoke the debugger.
this: https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-the-browser/
explains how to start a debug session from scratch on a simple binary. we're not quite so simple, we're an interactive app with wasm stuff running deep within that.
we could still break on the first wasm instruction hit & drop into the lldb gui from the command prompt when that occurs.
assistance welcome getting to that point.
then ms code support once that's working, maybe.
or a different route if you prefer.
so, we have these options - any preference ?
https://clang.llvm.org/docs/ClangCommandLineReference.html#debug-information-generation
let's start from basics: do you have wasi-sdk installed?
yes, latest installed this morning.
all our examples link against it
when you produce wasm code, can you run llvm-dwarfdump (from wasi-sdk) to check debug information presence?
however, we don't call your main. we have our own entrypoints we call one to init, one per tick process
you still load code via wasm_module_new
, is it correct?
I could, but right now we don't have any as I haven't passed the flags as was only concerned with release build to start with
yes
so first job is compile debug build, with debug info, of which there are various formats, hence the q which format would you prefer
llvm's wasm output with dwarf section is what we are looking for
-g --debug
or something more specific
clang -g
will do the trick
k, so -g
don't need --debug ?
you can drop optimization to -O0
if you want too
/me never used --debug
didn't actually have optimize on, but should for release build. thanks.
JIT can be configured to transform DWARF via https://github.com/bytecodealliance/wasmtime/blob/master/examples/fib-debug/main.c#L18
, so you want :
wasm_config_t* config = wasm_config_new();
wasmtime_config_debug_info_set(config, true);
... if we're running in debug mode. on it.
you can also choose to not run JIT optimization via wasmtime_config_cranelift_opt_level
(see https://github.com/bytecodealliance/wasmtime/blob/master/crates/c-api/include/wasmtime.h#L35)
lets keep it simple & just get the debugger working first, then second pass tweaks if that's ok.
It is not really a "debug mode" but flag to compile debug info along with code (wasmtime_config_debug_info_set
is)
well, its something that's only needed if we're debugging. or you suggest I always have this set ?
It will degrade to startup performance and memory consumption
I would pref it with environment at this moment
k, will do. thanks
/me is working on caching debug info with code at this moment
good to hear. I'll just be happy to have it running for now :)
if you using Linux, LLDB-10 or GDB will work without additional configuration
k, that's compiled in. let me grab my tea then lets see if its that simple (from user perspective)
example you provided called wasm_config_t* config = wasm_config_new();
no matching delete. not sure significant but spotted that.
own wasm_engine_t* wasm_engine_new_with_config(own wasm_config_t*)
-- it is consumed/owned by engine now
k
ah that's what your weird own macro means :)
lldb has a python36.dll dependency. python 3.6 only available as source :)
if it needs it, llvm should include it in their bundle.
grumble :) if you have one, you're as trusted as anywhere else I'm likely to find it.
or I could just build it I guess.
windows
alright... it is all in your hands from this moment
so, my next job is building python3.6 from source, which I wasn't expecting. we'll ship it with our stuff so all our users don't have to.
/me heard it works there, but never tried
yup. that part not your problem, but fyi. your stuff harder to use when a key component (in this case lldb) doesn't just work (tm)
is there something in vscode ?
dunno. doing lldb from command line for now.
building python should be easy, but we'll see.
@Steve Williams did you try lldb-9 instead of lldb-10?
Last updated: Dec 23 2024 at 12:05 UTC