lldb requires python36.dll on windows. python 3.6 is only available as source & I can't be bothered building it. if anyone has a trusted python36.dll it should be up somewhere to smooth the flow around wasmtime toolchain. llvm guys should ship it, but they don't.
I've just grabbed a random download off the interweb for now, which isn't ideal, but it'll have to do. would prefer to use/ship something a little more trusted.
yuri, why go backwards. its one dll to fix this problem.
I have it running, but with a dodgy dll I downloaded. might be fine, might not :)
& therein lies a security issue so this gap should be patched properly.
our entire distribution needs building from scratch on a clean system at some point. right now, its just make it work mode. you have been warned. virus check our stuff if you run it. think I'm clean, but who knows what's lurking.
"lldb was not built with gui support" using standard download from : https://releases.llvm.org/download.html#10.0.0
we all love having to build each others stuff every 5 minutes :)
so ... looks like a hop straight to one of the visual studio code thingies as not in the mood for building llvm from scratch either.
if anyone knows which is the best wasmtime compatible visual studio code addon, recommendations welcome.
post above says CodeLLDB just works, so lets try that.
new to vs code, so will take me a while to get head around it.
if any llvm devs around please build lldb with gui and ship whatever python dll you need with your windows binaries, thanks.
no joy yet. got lldb to execute our app from visual studio code but it won't set breakpoints. seems to want to debug our binary rather than the wasm code.
configuring lldb in vscode as follows : https://pastebin.com/xZJH5x6h
unsure how to tell it please debug wasm rather than app binaries.
if you have app callbacks that called from wasm, can you set breakpoints there?
so major question here is to check if GDB JIT interface is working on Windows LLDB. if you can break at any code that was called from wasm and you can inspect call stack, it is a good news
I could in our debug build but that's not what I want to do. I want our app in release mode with wasm stuff in debug.
sure. can you still confirm the above though?
yup
if you break in the running code (+wasm) and type image list
in the debugger terminal, you shall see a module with "JIT" in its name
if it is there then you are almost done -- you just need to enable breakpoints on all files in vscode
noob at lldb. gui doesn't want to let me break. seems like I have an lldb console.
what's the command to break ?
sorry, I usually just visual studio & go :)
b file.c:34
or b foo_function
not set a breakpoint, just halt wherever it is so we can do that 'image list'
hmmm, is there pause
button?
yeah, its ignored but I have a console
can't we do it from there ?
ctrl-c
normally do the job in cli
maybe I get you a linux build & we do this over there first.
it will save some time, yes
leave this with me for a while. I can't drive vscode properly yet. need to mess with it a bit more. linux version in due course if we need that. it doesn't have everything yet but should have enough to fire up & debug our wasm examples.
also you may try smaller example such as https://github.com/bytecodealliance/wasmtime/blob/master/examples/fib-debug/main.c
can also ship an infinity version with debug mode. this is mostly likely an I can't drive lldb/vscode issue. so maybe I need to hop out of the way.
there are also https://github.com/bytecodealliance/wasmtime/tree/master/tests/all/debug/testsuite
yeah, think you're right. lets get a simple example running under the debugger first.
k, back up a step. lets drop vscode & work from lldb command line
sorry for the delay, here's "image list" output
sorry, that wasn't during a run. this one is though. ctrl-c from cmd line as advised.
not seeing anything with jit. maybe I messed up adding your debug support. will go back over that.
yeah, that's missing "JIT" module, means debugger did not get any info about JIT code
good news is vstudio code was doing as it should. can't break on anything it doesn't understand.
it can be that windows support for lldb is not on the par with other OS
vscode can be configured to set breakpoints on everything
or it could be I've goofed. others have got wasmtime debugging on windows.
can you try simple code on linux?
yeah but I haven't given up here yet.
leave it with me. you've told me what to look for when its working. will let you know when I get there.
& I will try linux if no joy windows
got this to enable debug stuff, with an audio cue so I know I hit it.
https://pastebin.com/rqNqkTAP
did I miss something. its just that & compile with -g
missing a linker flag ?
checked wasm with llvm-dwarfdump?
not yet, that's next I guess.
build script as follows : https://pastebin.com/rfUWxrd8
http://advance-software.com/misc/app.wasm
don't seem to have llvm-dwarfdump windows. might have to boot linux after all :)
nope. don't have it. llvm 10 standard binary distribution, windows is rubbish :)
got llvm-dwarfdump linux, so ran that. don't know what I'm doing with it yet. didn't seem to spot anything interesting so perhaps entry level fail & no debug info in the wasm. just compiled with -g as requested. maybe that's not enough.
Line 27 , no “-g”
there is, it expands from COMPILE_OPTIONS, which gets it from EXTRA_COMPILE_OPTIONS
expands as follows :
on line 36, we have the actual compilation, which includes -g flag
as I have no clue how to use llvm-dwarfdump can I get a minimal command line or output to look for please
I can experiment with other flags into the compiler to hopefully generate some debug.
this is almost comp sci 101 fail territory :)
this bit doesn't require running any of our binaries, just running llvm 10.0 distribution out of the box, with make script above instead of the release script shipped in our sdk above.
realise its my problem, just saying its safe for others to help identify why we're compiling without debug info if you wanted to.
am I missing an obvious link flag I need ?
maybe clang is weird & the position of the flag on the command line matters ?
llvm-dwarfdump just prints entire dwarf sections, so if nothing then it’s empty
I place -g before files but it shall not matter
k, so I got nothing. so we're at bottom of the class here. how embarassing :)
wasm-ld just combines these sections
Do llvmdwarfdump for obj file
llvm-dwarfdump app.o
app.o: Invalid data was encountered while parsing the file
Is dwarfdump new e.g. from wadi-sdk
nope. I have no idea what version., should update it.
however, whichever version I have says this :
llvm-dwarfdump app.wasm
app.wasm: No available targets are compatible with this triple.
app.wasm: file format WASM
.debug_info contents:
Right. Use one from wadi-sdk
link to wadi-sdk please. jfgi but not obvious
The one you have probably from 10 years ago :p
Wasi-sdk it is
llvm-dwarfdump --version
LLVM (http://llvm.org/):
LLVM version 6.0.0
Optimized build.
Default target: x86_64-pc-linux-gnu
Host CPU: skylake
so yeah, my linux box needs an update
ah, it is wasi sdk & so a typo
Right. You have wasm-ld so you may have dwarfdump near it
nope. gonna do that linux. upgrading my llvm to 10.0 ubuntu
yup, 10 linux has it, 10 windoze doesn't :)
pre-built binary distributions
then as no installer ubuntu, looks like I just drop the directories into the file system
LLVM (http://llvm.org/):
LLVM version 10.0.0
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: skylake
from : llvm-dwarfdump --version
so think that's how you install it :)
tired. simple obvious things aren't working so gonna stop there for today & get something simple compiling with debug info in the morning.
cheers all.
k, progress. ported my make script to bash, compiled our thing ubuntu, llvm 10. ran llvm-dwarfdump app.wasm got a ton out output, unlike yesterday :)
apparent bug llvm 10 wasm win64 : debug info not generated when requested, though need to verify.
image list from llvm on windows not showing anything jit related, unless I'm blind. this is with the wasm with debug in it compiled on linux.
still running on windows, next step is perhaps run linux. which wouldn't hurt anyway.
https://pastebin.com/fL3TpAqn
however confidence low that lldb 10 precompiled binary version on windows is solid anyway.
from wasm. for standard compilation, it gets exercised plenty.
so, back to basics until standard stuff is working as expected. maybe a wasmtime.exe example next, rather than our stuff.
looking at debug example posted above. we have differences. its not just this :
https://github.com/bytecodealliance/wasmtime/blob/master/examples/fib-debug/main.c#L18
most of the entrypoints in that example are wasmtime methods, whereas I assumed wasm_c_api would be sufficient.
seems I assumed wrong :)
as of 0.16 you have a regression, yury
./main.c:74:68: error: too many arguments to function call, expected 5, have 6
error = wasmtime_instance_new(store, module, NULL, 0, &instance, &trap);
store parameter needs removing from that call.
no cargo.toml so instructions in main.rs cannot be completed.
for fib-debug
if I could have that missing file, please, I should be able to run your example as-is to see if I can reproduce expected behaviour :)
sorry misunderstood - main.rs is equivalent of main.c which I don't need. the wasm is in wasm :) with its toml :)
cargo build -p example-fib-debug-wasm --target wasm32-unknown-unknown
should be in make.sh in the wasm directory, not referenced in main.rs which I'm not using :)
a make script so all of that just works would be nice :)
note how my stuff has that :P
welcome back... so you are on linux today?
for right now, yup.
"too many arguments to function call" means you are trying to use old version of wasmtime with new example
API changed after my PR
I'm using latest shipped version :) 0.16
0.17 is source only.
but if its the runtime that's too old, can compile 0.17 myself.
I thought 0.17 is released
it is, but only as source & I was keeping workload to the minimum.
yep, https://crates.io/crates/wasmtime
but if that's a requirement, then it is :)
got fib_debug running using main.c 0.16
next job, drop in 0.17
no debugging yet, just got my head around your build process.
here's that start of a make script - compiles main.c & installs wasmtime runtime. I'm a bit crap on linux, so could possibly be done better, but it works.
https://pastebin.com/hKznEJRC
that's right, I gave up on building 0.17 when I hit this :)
cargo build -p wasmtime-c-api --release
error: failed to parse manifest at /home/x/dev/wasm/wasmtime-0.17.0/Cargo.toml
Caused by:
feature profile-overrides
is required
this Cargo does not support nightly features, but if you
switch to nightly channel you can add
cargo-features = ["profile-overrides"]
to enable this feature
is it really necessary to use absolutely bleeding edge functionality on everything ?
:)
$ rustc --version
rustc 1.43.1 (8d69840ab 2020-05-04)
rustc 1.36.0 (a53f9df32 2019-07-03)
k, so how do I update that plz :)
rustup update
?
apparently, I avoid the horrid thing as much as possible as it lacks elegant c/c++ syntax :P
did you install via rustup
?
at some stage I suppose.
running an update
its like the pascal people showed up & told us how its gonna be & the c++ guys when, ummm ... no ... but I digress :)
1.44
alright, bleeding edge
x@dev:~/dev/wasm/wasmtime-0.17.0$ cargo build -p wasmtime-c-api --release
error: failed to read /home/x/dev/wasm/wasmtime-0.17.0/crates/wasi-common/WASI/tools/witx/Cargo.toml
Caused by:
No such file or directory (os error 2)
this is why we have binary distributions of things - so everyone doesn't have to go through dependency nightmares :)
how do I install that wasi crate thingy please.
let's cleanup: cargo clean
and git submodule update --init
?
its unhappy doing a cargo clean, same error.
what about submodules?
I don't need to do this. can you just build 0.17 & post it, no is cool if you can't be bothered
not a git repository. I downloaded 0.17 from releases, not from git.
probably glitch in matrix, did you report it?
how do I pull that branch from git please
yeah, but then these guys with dark glasses showed up & I ended up here :)
git fetch upstream
&& git checkout upstream/master
normally works for me
guess I just pull wasmtime git trunk on linux, as I did on windows. cross fingers & hope its solid.
which is what you just said.
if I'm angry with what I see in git status
, I just nuking that with git checkout -f --recurse-submodules
pulled fresh trunk
x@dev:~/dev/wasm/wasmtime$ cargo build -p wasmtime-c-api --release
error: failed to read /home/x/dev/wasm/wasmtime/crates/wasi-common/WASI/tools/witx/Cargo.toml
can we have a binary build of 0.17 please.
https://github.com/bytecodealliance/wasmtime/releases/tag/dev ?
ah, that's new :)
when you go this way, it just shows source : https://github.com/bytecodealliance/wasmtime/releases
thanks.
There was a build problem on CI, so exact 0.17 might be missing -- the issue needs to be opened
well, we can hop past this. if there's a binary 0.17 which you've linked, thanks. I can just use this & the matrix can resolve itself :)
the Assets is what you are looking for
? I'm just wanting to link 0.17 to main.c from fibdebug so I have the same API you have in your example & as close to edge as possible without losing my mind :)
@Dan Gohman can we release 0.18 sinse 0.17 did not publish any assets?
Sure
I wonder if 0.17.1 is a thing for us
whatever works :)
k, 0.17 build, runs ubuntu. no debugging yet but works
building lldb 10 from source as seems to be a requirement :)
lldb version 10 installed, ubuntu
alright, alright, alright... let me know if I shall pull mine from the closet
think that's a private matter :)
ran fib debug thingy.
just let it run all the way through. not sure if that's what you wanted.
so, not seeing anything jit there. to be clear I ran that after a run of the app. didn't break inside it.
sure if store is cleaned up -- there is no JIT'ed code
place a breakpoint in your app just before/after the wasm function invocation.
k, so that's expected. I have no clue how to use lldb from command line yet :) and of course compiled without gui :)
is there the equivalent of DebugBreak() on windows I can just compile in ?
https://www.nesono.com/sites/default/files/lldb%20cheat%20sheet.pdf ?
]
thanks
normally you type b main.c:234
to set a breakpoint at specific line, r
to run/restart, c
to continue, q
to quit
you don't need to know much to drive debugging session, but it will be useful to see what you did hen you post terminal in the pastebin
it is impossible to paste your mouse clicks
k, so to keep this simple, how do I single source line step please
s
or n
tried that - invalid process
so I have to start it somehow first ?
r
?
that runs the whole thing
so I have to put a breakpoint. I can't just step in a line at a time.
so breakpoint at main
god I hate this - we've moved on. its like hanging out with the vi is great crowd :)
right, it will break on set breakpoint though, see e.g. tests https://github.com/bytecodealliance/wasmtime/blob/master/tests/all/debug/lldb.rs#L71-L74
I don't have a set breakpoint. I just want to do like visual studio. f10, first line, next line, next line.
but you do set a breakpoint at first line, no?
in visual studio, no. turns out you can step and it figures out you wanted to start at the first line of the program :)
but that's not important. this toolchain works how it does.
yeah, usually hello world programs are debugged this way
this pretty much is hello world. its only about 50 lines
breakpoint set --name main
apparently
or b main
which should be implict if you step from an unstarted program, but anyhow :)
omg its working :)
s steps in, not wanting to dive deep n is next high level instruction ?
yeah, but I'm interested in image list
at
wasm_extern_vec_delete(&exports);
so image list here
you're not gonna like this :)
I spy [ 11] 54F9EC54 0x00007ffff7fc7000 JIT(0x737b80) (0x0000000000737b80)
ah, so it is :)
so, we've got the basics working. next step hop back to windows & see if I can get it doing the same thing.
thanks for your assistance & patience :)
hold on, set breakpoint in wasm code
how plz
use source file name and line number
just like you use mouse, but using the keyboard :P
yeah, mouse was invented so you didn't have to search through cheat sheets :)
this is like arguing with blender artists who love their key combos when I prefer 3dsmax gui but anyways :)
repeatable is a key here, mouse is an art
mouse triggers events that can be captured & logged, but we digress. you want to stay with 60s tech, we'll stay with 60s tech.
(lldb) b fib.rs:4
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
that's from a fresh start. guessing that's too early. hasn't loaded yet so knows nothing about it.
b main
or just b fib
when the c code is reading imports/exports you should have enough info for wasm breakpoints ?
apparently so
yeah, if wasm code has valid DWARF info
seems happy.
looking for continue command
c
?
seems happy :)
is it good?
nah
try bt
should say var, not let mut
it works, the syntax is horrid :P
you are using wrong examples, did you see https://github.com/bytecodealliance/wasmtime/blob/master/tests/all/debug/testsuite/reverse-str.c ?
to be clear. system is functioning as expected. thank you. I have a syntax quibble but that's an issue for another day.
I used the fib example you linked above. think my whine about rust syntax has confused you.
install vscode on ubuntu and try to drive debugging via GUI
that sounds crazy
nope, vscode is using LLDB
yup, might even work :)
if so, screw up is bcoz I was using wasm-c-api entrypoints but you require wasmtime api calls ?
not sure
generating of DWARF is an overhead, the engine needs to do be configured to spend CPU/memory for debug info
c api "outsourced" this type of operation to implementers
vscode, linux refusing to start, but I had that working windows & not concerned linux right now other than diagnostics, which we've just completed.
so, let me head back to windows & repeat the above somehow. might have to compile llvm trunk or 11 candidate as 10 wasn't behaving.
cheers. leave that with me for now. I can see we can debug lldb, regardless of what vscode's doing.
building llvm trunk, windows, gonna be a while.
c api "outsourced" this type of operation to implementers
which is why I don't understand why you have so many wasmtime calls in fib-debug. surely just the first call to set debugging info as that's not present in wasm-c-api is enough. then standard api.
& even that, surely an environment variable would be better, then you can override & enable debug from any wasmtime runtime without anyone having to modify anything.
right, but the main question is does it work on windows?
the environment feature is good, but irrelevant
fighting with llvm build system. their latest windows snapshot is 20th feb. 10 released in march.
its not irrelevent, its a refinement once we're working.
this is what I hate about open source. everyone's like "but you can build it yourself". I. don't. want. to.
I'd like a beer please. sure sir, there's a field, go plant yourself some hops ...
:)
which version of LLDB is included in vscode plugins?
right now it doesn't matter bcoz clang doesn't generate debug info and I can't ship a toolchain that requires our users to switch to linux to compile their scripts.
just built llvm windows using standard cmake environment, which built everything except what I want, so going through more slowly, second pass to see if I can get thing to do what I want.
this "windows snapshot build" is older than the current release : https://llvm.org/builds
realise it's not your project, just sayin' :)
going with this as a llvm configure script :
cmake ../llvm -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;lld" -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD="WebAssembly" -DLLVM_BUILD_EXAMPLES=0 -DLLVM_INCLUDE_EXAMPLES=0 -DLLVM_INCLUDE_TESTS=0 -DLLVM_INCLUDE_BENCHMARKS=0
nope, not that :)
/me would just use https://github.com/WebAssembly/wasi-sdk/ as a base
have you tested windows, coz my understanding was you're linux only.
https://github.com/WebAssembly/wasi-sdk/blob/master/Makefile#L7
hence going trunk to see if whatever's wrong has been fixed.
have you used your sdk tools to compile with debug on windows & confirmed you get debug info with dwarf tool thingy who's name I can't remember ?
:)
llvm-dwarfdump
llvm-dwarfdump
we need to be able to compile wasm with debug on windows or there's no point going further with any of this as our only viable dev platform right this minute is windows. our plan is complete there, then fill in the gaps linux & others.
that build still going, thought it had failed, but just some warnings.
again, that's a pull, fight dependency hell & hope rather than a install package. I'll give it a go. thanks.
completing llvm build I have going first. may as well, its half way thru.
wasi-sdk : what do I run windows, please. no make, that makefile isn't nmake compatible
got mozilla build tools which does have make, but it doesn't have cmake :)
mozmake?
dunno, I'll figure something out.
however all of this is some way from it just works (tm)
such is free
k, got cmake in my mozilla tools cmd thingy
it can't find llvm stuff now.
so must be a step before make that i've skipped
backing up a step, why am I not just running https://github.com/WebAssembly/wasi-sdk/releases
wasi-sdk-11 mingw ?
I'll build if I have to, but surely that's what I want, your most recent built tools. if they work, we're good.
I was using standard llvm-10 - haven't tried this yet, so maybe that's the hassle free fix.
its only 6 days old so unless you've fixed something I need more recently than that, think that's where I should be.
k, progress :) compiles windows with debug & do have llvm-dwarfdump there as its in the mingw distribution.
yay :)
solution was to use wasi-sdk tools rather than standard llvm-10 equivalent, as advised, thank you :)
no lldb in that package. I should use standard llvm 10 version ?
if its missing & you plan to add, please build it with curses so can use gui
using lldb 10 for now
ctrl-c to break
no JIT. as expected, as that's just the same as compiling wasm on linux then running it on windows as yesterday.
so back up a step, run fib-debug windows, see if can repro behaviour on linux.
test_app is fib_debug compiled with debug info, windows
so that lldb sucks
build trunk lldb ?
sanity check. standard lldb, standard simple c program. see what happens.
ummm, losing it - was trying to debug fib debug linux on windows, hadn't actually built it. surprised it got that far. doh :)
k, built fib_debug using visual studio on windows as clang was giving me weird errors. as our stuff is vstudio, that's probably better as closer to the same thing.
stepping thru using lldb
that's using wasmtime from here : https://github.com/bytecodealliance/wasmtime/releases/tag/dev released today.
can you guys please confirm your stuff works windows. doesn't seem to for me.
Could be that GDB JIT interface does not work on Windows. can you file an issue? maybe someone can weight in before I look at it?
long shot: can you try settings set plugin.jit-loader.gdb.enable on
before doing r
sure. let me try that.
can mozilla get yury a windows box please :)
... in the closet
I gotta be bi-os so have u :)
this times, tri-os is acceptable
yeah, got all that fun ahead. quad os if we're going android and mac stuff
and then we have ps-5 & xbox next fun & games. but lets keep it simple for now.
not spotting any difference.
https://pastebin.com/mTxufwp9
where would you like me to raise a bug
should be easy enough for anyone else to reproduce. there's a possiblity I've got a weird setup.
so you might like a confirmation.
the wasmtime issue tracker is fine
here's my fib_debug directory with a visual studio solution in the make subdir & windows binary & the rest of it in bin
http://advance-software.com/misc/fib_debug.zip
can build yourself but that might be a helpful shortcut
I'm done unless you want me to add anything : https://github.com/bytecodealliance/wasmtime/issues/1850
right time for some zzzzz for me, have fun :)
whilst you're at it, if fib_debug can run with standard wasm calls instead of wasmtime calls, I think it should. should only use non standard calls when we have to.
& reminder of the environment variable enabler to remove need for non-standard api altogether.
though whatever works :)
hope going well. let me row back on request to activate debug mode with an environment variable.
reason: that'd be global, but we'll want some scripting under debug control, some running normally. that just occurred.
BTW, i was doing some work on OSX and debugging didn't work. I managed to figure it out why so maybe this can help some people.
The root cause of it is that allowing the Injecting JIT debug information in LLDB has different defaults in windows/osx it would seem.
In the debug console if you run:
settings show plugin.jit-loader.gdb.enable
it will say default
, but it seems default
means different things on different platforms :D. So the fix is quite wasy.
If you're using Code LLDB plugin for vscode, you need to set this option in your settings.json
:
"lldb.launch.preRunCommands": [
"settings set plugin.jit-loader.gdb.enable on"
],
Then, after your module is registered, you can type in DEBUG CONSOLE image list
and you should have a JIT(0xADDRESS)... in there as the last entry
This is excellent, thanks @Alexandru Ene . I'm wondering, should we add this somewhere in our docs perhaps? It seems like a useful bit of info. @Till Schneidereit what do you think?
We could have a Debugging section and troubleshooting steps in case debugging doesn't work.
I can raise a PR with that as I did a bunch of troubleshooting recently around it.
There are also known issues as https://github.com/bytecodealliance/wasmtime/issues/1896 or https://github.com/bytecodealliance/wasmtime/issues/1850 , I think I'll mark them with wasmtime:debugging
Last updated: Dec 23 2024 at 12:05 UTC