 Awesome. Hi everyone. Hope you had great lunch. I'm super excited to talk about navigating different strategies for debugging WebAssembly. Thank you so much for coming here. So a quick introduction about us. My name is Ashwin Kumar Uppala and I'm a program manager at GitHub. I'm Shwai. I'm a developer at Engineering Research. Super excited to be back here. Last time I spoke at CloudNative, awesome day was actually in 2021 virtually when we just kind of opened up after COVID. So it's good to be back and present in finally in person as well. Awesome. So the CloudNative awesome is growing. It's going very fast. In fact, my first experience with the WebAssembly was just one year ago at Open Source Summit and KubeCon. And since then the proposals have been increasing very fast. And it is so cool to see how many awesome proposals we have so far. In fact, recently we had the awesome garbage collection made available in Chrome for adoption, which is very good news. But I was curious while I was trying to explore more into WebAssembly and in one of the talks that I gave a few months ago in CU Navigate about the accessibility for WebAssembly in the communities that we have is how do I debug WebAssembly? Like if I'm trying to learn as a beginner or someone who has made a transition into WebAssembly or someone who just want to give it a try, how do I make sure that I'm doing it right? So what about the debugging? Do we have enough proposals so far in WebAssembly space for debugging? Well, it's a bit challenging right now. There isn't a standardized wasm proposal for debugging WebAssembly yet. This means every WebAssembly runtime or the product or the application that we use or that you are trying to use uses a different set of approach towards debugging. Speaking of that, Shiva, do you want to give us a few examples in detail? Yeah. So as part of the presentation, I'm a long time wasm, it's a common contributor and I've not really contributed much to wasm or to was zero yet, but I wanted to reach out to the maintainers of all of these different WebAssembly runtimes that are there and just kind of understand like what kind of approach are they kind of proposing towards debugging because as kind of I should mention that since there's no standardized way of approaching towards debugging something like wasm and which is standard as approach for machine learning and neural networks and WebAssembly. So I reached out to the different founders and the maintainers of these different WebAssembly runtimes. So was more, of course, the focus right now is a very well-known WebAssembly runtime that can allow your WebAssembly to run on edge, on server side, on cloud native. So they don't really have any specific way or approach that they are following right now. So it's kind of a black box for that particular WebAssembly runtime. Then I also had a word with one of the maintainers for wasm edge and this one of the approach that I have personally also tried to use is of course like wasm edge and the maintainers primarily are approaching this towards two different ways and these are again not some really unique manners but of course some of the common techniques that people are using right now in order to debug WebAssembly. So the first one is the end of time compilation. So in this case you're using your AOT compiler and of course there might be some issues that might prop up in your AOT compiler. So of course in this case what you might want to do is instrument some code or perhaps just change some of your original code to try to find the original issue. So of course when you're using your AOT of time compilation you'll be generating your assembly bytecode and then of course you can try to debug that asm that's generated from your compiler. Another approach is of course just trying to use a very native way of trying to identify what is that particular piece of your code that actually might be causing that issue. So if you're having let's say you know the idea really is to be able to pinpoint or boil down to that specific piece of your code logic that of course once you're converting your source code into the WebAssembly module is to identify that particular source code within you know your entire source directory that might be causing that particular issue. But of course this is kind of a hide and seek where you're trying to put in a lot of effort in trying to identify that very exact issue and it can be very time consuming. But of course like both of these approaches one of the biggest downsides is that if you're not aware of the WebAssembly execution model and how stack tracing all of this works then it might be very difficult for someone from a non-Wasm background to actually try to debug WebAssembly modules if you're not aware of these approaches. Then of course Wasm time which is one of the most mature WebAssembly runtimes out there actually does a pretty good job when trying to use your standard debuggers like ZDB or your LEDB in order to basically be able to find issues within both your guest functions and your host as well. So Wasm host might take a look essentially at a step-by-step approach of looking at how the Wasm host and your guest basically works. And then of course we have Vazero which is one of the newest or newer WebAssembly runtimes that based on Go. So since it's completely based on Go, you can very easily use the strong debugging capability that you get within your Go functions and try to also then again point out where exactly these two might be inside of your WebAssembly. So of course I can in this particular approach you're really looking at the standard source code debugging where you're trying to identify the issues within the source code rather than directly in the WebAssembly module itself. But of course Vazero also comes with support for Dwarf. Not fully supported yet but of course there is support and of course other is that you can use some operators that can get you some telemetry data and we'll be of course looking at some of these approaches as we proceed in the presentation. Wow, that's a lot of options you are. It can be a bit overwhelming when you have so many choices for so many different runtimes to debug them. Let's categorize them. Let's make it a bit more simpler on the ways to debug WebAssembly. In general, when you are learning a language or any other framework or in general, the standard debugging style is the print line debugging where you just work directly with your source code or you can also have unit tests that also works just fine. Then we got standard debugging like LLDB or GNU debugger for if you want to get more into the low-level debugging tools and I'm going to be explaining a bit more about browser dev tools which should be the most accessible for all of us to use that when working with Wasm projects. And after that, we'll try to give you a demo of some of the debugging applications. If not all, a couple of them are like ModServer, SDK, and Wabbit which stands for Wasm Binary. Now these are applications which are supposed to be easy to use and should help you debug very specific Wasm applications. Now, to give you a more dynamic demo on the ModServer and these debugging applications, before that, let's go and try... So of course, like what we're seeing right now is even with the different runtime approaches, you saw that we kind of collected all the different approaches that the different runtimes and the maintainers are usually following. And this also does not just apply to the runtimes, but also to actual companies where they're adopting WebAssembly. So it's whether the WebAssembly first companies or companies that are adopting WebAssembly. So these are some of the approaches. So one of the things that we kind of also focus on is primarily focused with how something like Wasm Time is able to use LEDB and something like, let's say, Wormer, which is another WebAssembly runtime, actually does provide a very comprehensive way of being able to do debugging. And of course, I'll recommend everyone to check out the GitHub repository as well for Wormer. I think it's actually inside the WebAssembly or in the bytecode lines. So they have given a very good brief of how you can actually debug not just with the AOD style, but also with LEDB as well. And of course, with Wormer, you also get support for DWARF as well. So you can use DWARF and we'll be talking a bit more about how to use DWARF. And of course, outside of Wasm, like we just talked about, Wormer, we also have the Wasm Time. For some reason did not load up the, so that's fine. But the idea with Wasm Time, as I've also covered before, is that you're using your typical LEDB and again, like to basically get your stack trace and be able to get some debugging information. And you can just look out on the official Wasm Time documentation that kind of talks more about how you can use the LEDB to get information about both your WebAssembly host and also your guest functions and kind of just do a step by step debugging off of both of these. Now, before I jump into the browser debugging, let's brief single slide to give you a brief idea of the technologies that is used for debuggers in the browser. The first solution that we see using is the DWARF, which is used to compile low-level languages like C and C++. But yes, we got a couple of problems there that not all compilers are supported by DWARF. And the debug data sometimes can be big, which can be hard to go through. We can solve that problem by using something called SourceMaps. SourceMaps splits that debug data using a debug file. It can make it easier to read. But then the new challenge we have here is to put them back together after we use the SourceMaps to decompile that code. So these are the two underlying technologies that we see for debugging on the web. So let's take a small sample here, a small example. This is a simple C program which kind of asserts if X is greater than equal to Y. If it's not, it should throw me an error. Now, first, what I'm going to do is I want to make sure this thing runs in my web. So to convert a C program into a WebAssembly format, we use M-scripten. And after we have done that, I want to go ahead and enable WebAssembly debugging tools in my DevTools of my browser. Any Chromium browser should work. It doesn't have to be Chrome if you're using Edge or anything else. It should have this under the experiment settings. So I'm going to go ahead and run this program. And once I've enabled the WebAssembly functions in my Chrome DevTools, you should be able to set breakpoints for your program. And once I enable pause on caught exceptions, and if I just go ahead and take a closer look at the scope what's happening here, I can see the parameters where the program goes wrong or throws an error. And if I look below at the call stack, I can see the function that is going on incorrectly. Now, this is a very, very simple sample of how I would try to debug applications on the web. So, yeah, moving on to DevTools. Yeah, so far what you've seen is we have looked at some of the standard approaches towards like print line debugging with your standard source functions or source code itself. Then, of course, we have the ability to use something like your standard debuggers with LLDB to get more in-depth information about your wasn't modules. And then, of course, right now, we'll also look at the approach. And of course, the approach covered by Ashwin was that one way is to just take your wasn't module and the simply like a simple old function to just run it in the browser and get some details with the help of gov to get more details about the call trace and all that. So, other one that of course we are seeing right now and I'll kind of argue calling this as standard debugging but more towards tracing and monitoring your wasn't modules. So, these approaches might not directly tell you that, hey, like this is the particular issue in your wasn't module but they will all, but at least they will give you enough information on what are some of the key aspects that are probably missing from your wasn't module. So, whether it's like certain imports or exports that are missing or certain check files that are not, you know, pushing your wasn't module into production because of course what we don't want is, you know, a non-standard way of like compiling your wasn't module and then seeing that, you know, it just throws an error. So, really the techniques that we are kind of now going to cover about DevTools is to monitor and trace your or kind of instrument your wasn't modules to ensure that we do not push faulty wasn't modules into production. And of course one, like before we talk about these particular techniques, the major point that we want to kind of highlight over here is that generally we are seeing these wasn't modules as black boxes, right? So, yes, we are able to get to know about the details about the input data, the output data, but we're not really concerned or I mean we have not been able to find very efficiently what is actually happening inside the wasn't module itself. So you'll get all this data about the input, outputs, and what type of was he calls we are making, but what's actually what exactly is happening because if you consider when we are basically taking our main source code and compiling it down into the web assembly binary, most of the time we are losing a lot of information because the wasm binaries are very small in size. So we are losing a lot of information in this process and it's very hard to understand like what is happening if you're not retaining that metadata. And of course, like another issue that we kind of see with these kind of instrumentation techniques or these monitoring techniques is essentially when you are trying to generate these logs, you're also generating a lot of noise as well. So of course, like for example, if you were just having a simple wasm module you convert into the VAT format, probably the VAT file might be 20, 30,000 lines of code. So it can be very hard to debug those directly if you're trying to like, let's say, generate logs from our wasm module. So these approaches are of course not giving us the full picture of what's happening inside the wasm module and then of course it generates a lot of noise that essentially is not very good for if you want to do quick and efficient debugging. So that is why we'll now talk about some tools that do help in this aspect. So of course, the first one is modsurfer. Now modsurfer is not really meant to be a tool for just directly debugging your web semi models, but it does give you enough information about your wasm modules. And in fact, like in one of their latest approach that they have kind of showcased and I like to now quickly show a demo over here is to basically head over to the main website. And I hope everyone's able to see this over here. So essentially what this particular new interface for modsurfer is, and this is pre-leased by the way, is that you can actually directly inspect your wasm modules to get to know about the import functions and the imports and the exports and all the different functions that are being used. So you simply just have to go ahead and upload a wasm binary over here. So let's just take an example and we have prepared some demo of using wasm edge with PyTorps. So we'll be using one of the modules that we have created. So of course we should expect to see some wasm and functions that are being called over here or being invoked. So we'll just quickly go and choose one of the wasm edge PyTorps wasm modules. Let's just go ahead and select this and add it to inspect this. And then we'll click on upload wasm. Let's try one more time. That's weird. Okay, let's just choose. So let's take a couple of seconds and then we should get very good information about what's the complexity of the function of this wasm module what's the source code of the wasm module itself. It will actually also load a small JS code that you can actually just now go ahead and run in this in the browser itself. So if you want to just get some details with Worf, you get some start code that actually you know you can directly load inside of your source code in a JavaScript function. And then of course you get the entire list of your imports and exports which this particular wasm module is using. So you get information about all of them. So of course you'll also see wasm because this wasm module was generated by the wasm edge function that we created for another conference. And then of course another like unique thing that's actually being done with Fermion Spin you must have probably heard about the service AI that's there. So the Dallas team basically collaborated with the Fermion team to generate insights about the wasm module itself. And in fact it can just tell you some additional details about what is the intended use of this particular wasm module. For example in this case we were trying to generate this PyTorps based function that would basically allow you to run PyTorps on the edge. So it also kind of gives you some insights about how you could use this particular wasm module might be used for embedded programming. But the unique thing about this particular tool is essentially this check file. So the idea over here is that with the help of this check file and you could basically include this check file in your GitHub action or any CI CD action that you could run and essentially what it's telling us is that before you push your wasm module into production you want to ensure that whether it matches the certain imports and exports that you want it to have or if you want certain for instance let's say what is the size of the actual wasm binary that gets created. So if there are instances where your wasm module does not meet those particular things whether it's missing certain imports or exports your CI will basically fail and they'll prevent you from pushing your wasm module directly into production. So that's a really great way and there's a quick demo that you want to kind of showcase. So we'll head over to our VS code right now and I'll quickly go over to this particular directory over here. So we have basically gone ahead and just taken the same example the same wasm module that we showcased and the only thing that we have changed over here is that we expect the maximum size to be 2.5 megabytes. Now if I try to just run the command and again this will be available on the mod-surfer documentation. I just need to run mod-surfer validate and then I will provide it the wasm module that I'm trying to run and use the mod.yaml and once I execute this and I run this it will tell me that involve what all cases am I failing. So for example one of the things that it failed on was the max size. Since we defined the max size to be 2.5 megabytes but since the max size of the module itself is 9 megabytes so what you're seeing over here is that even before you push your web assembly module into production you can basically create these checks even without having to worry too much about the actual module itself and Ashwin if you want to probably add something to this particular tool. Is the text side good for you all? At the back you can read it right? Okay awesome. So yeah we were able to work with the mod-surfer team to check out if we can use this tool. The caveat here is you do need to have mod-surfer CLI to use this check file here but yeah we were able to get this done so I'm so glad we were facing a lot of bugs quite recently before our demo. Alright then moving on to the next tool. I know we are running out of time but just to kind of talk about the Observe SDK. So Observe SDK is another tool that allows you to essentially add observability metrics so once you are like let's say trying to find certain issues within the was a module itself we are basically using Observe SDK and you can directly send your logs to any kind of a tracing tool like Yager to open telemetry so in this case like the example that now we'll basically show and again the point over here is that in this case the SDK basically tracks all the functions and the memory allocations in the web assembly module right? So the idea really is that it's not just focusing on the imports and the exports but it'll also take a look at all the different function calls that are actually also happening right? So one of the drawbacks that we spoke about earlier about instrumentation techniques not being able to know what's there inside the was a module itself is what is overcome with the Observe SDK and we have a quick demo to basically quickly showcase that so in this case what we have over here is this Observe demo and I'll just quickly zoom in this more we have a main.iris file this basically is a standard hotel to standard output so this uses the dialect so SDK for observability and we are simply just again taking our was a module taking as an input and trying to find you know any issues that we are able to find so over here we basically are taking a faulty Rust code so this is a very simple Rust code that does have an issue so what I'll just go ahead and do is I'll navigate quickly over to my Observe demo and I'll quickly go ahead and run cargo run and essentially that what will allow us to do is I'll just go go ahead and do cargo run and then we'll run the instrumentate was a module that basically gets generated from the Observe SDK so that will basically give you the trace yeah so new one and then instead or it wasn't instead perfect so what this will basically give you is it gives you the call trace and the basically the stack trace the actual error that is there in your was a module so this gives you directly that particular issue so of course now you could even go further in this case we had like you know a non executable was a model like I mean not intractable but you could also make this intractable by except accepting certain JSON response so that you can get to know about the issues or the errors in your was a module on the fly like as you are kind of interacting another one final tool that's actually not launched yet and of course data dog actually just announced their observation integration very very in the very past few days another toolkit that I like to point out is being done by the actually got to know about this yesterday itself at the wasm social by the by the by the loophole last team is the wasm toolkit which essentially is the best of both the worlds when trying to use the Observe SDK because they are giving you information about not just like what's happening inside the wasm module itself but they provide a platform agnostic way or the language agnostic way so you could essentially have your was a module being run in any kind of a web similar runtime and we saw that issue like there are so many different type of website run times and all of them have these issues so essentially I can recommend you to keep in touch with the loophole labs because they are coming up with this and not you know spend a lot of time because we are running out of time slightly but I think and this is like one example for a deep for a goal and code where we could see like all the standard you know issues that are there and those are getting logged as well and this I'll recommend everyone to kind of just take a screenshot because these are all the different approaches that we covered today and the pros and the cons this is referred from a Shopify blog that is shared but yeah Ashwant if you want to probably close yeah a quick recap this is a quick recap of what we just talked about if you are the various strategies of debugging WebAssembly if you are using the native print line method or whatever method that prefers yes you are familiar with it but then the problem is like you cannot reproduce the behavior that you might be expecting while trying to debug WebAssembly in your application Shiva explained about LLDBA and was sometime along with other run times it has reasonable feature support but it can be a bit difficult when variables are involved our same goes for WebAssembly specific debuggers and browser debugger is always convenient and have a familiar experience but comes at the cost thank you so much and yeah you can scan the QR code to give any feedback about the session would love to connect with you on our Twitter so thank you so much thank you so much