 Hi, I am Thaiz and I have been working at Microsoft for four years, thinking care of the debugger, mainly for mobile devices and web assembly. Also, I am Brazilian, so I would like to say sorry about my English, and I hope you all can understand what I am trying to explain. The goals of this presentation are showing what are the biggest differences and challenges that we face to implement the Wasmite debugging with .NET in VS Code in two different execution modes. The one that we will call Wasmite, which is web assembly running inside the browser, and the other one that we will call Wasmite, which is the web assembly running without the browser. We can execute and debug in both ways, and I will explain how we implemented the debugger support for both of them. The first thing that I will try to explain is why we use the Chrome DevTools protocol, which we will call CDP from now on. So to start, I have to say that as our runtime already works for other platforms, we already had a protocol to talk to our runtime called soft debugger protocol, and we will call it STP from now on. The only way to talk to our runtime using STP was via socket, and it was not possible, as far as I know, to open a socket in Wasmite running inside the browser. Another reason is that we wanted to debug JavaScript and C-sharp at the same time. So we decided to use CDP to communicate with runtime, since we were primarily running Wasmite on Chrome. Here you can see a draw of how the browser communicates with IDE, with remoting the debugging enabled. It's important to remember that the IDE can be, either VS code, VS, or DevTools from browser itself. They communicate through a web socket using CDP. For example, the IDE sends a message to browser to insert a breakpoint, evaluate expressions, get local variables, and others. The browser also sends message to IDE to say, hey, I hit a breakpoint, so it's positive on the debugger. In our version, we put a proxy in the middle, which ends up intercepting all the messages between IDE and the browser, and checks if that message has any relevance for C-sharp code, whether it does what's necessary, and if it's not, we only forward the message. Now we'll show you some details of the code in case you want to start to understand more details. In this slide are all the links. Here's the code executed when the programmer inserts a breakpoint via CDP. It will receive a message of type debugger.setbreakpoint.url. Here is where it checks if the added breakpoint is a C-sharp code, and if it's a C-sharp code, it goes to the next method. The next method is where it writes in a stringy buffer following the STB protocol, everything that we need to really insert the breakpoint in the managed code. Here is where it calls the JavaScript function using the runtime-evaluate message from CDP. So we are in a C-sharp code. We will call runtime-evaluation using the CDP message, and then we will execute this function on browser. We will use this JavaScript function on browser side. Here is the JavaScript to wrapper function, which we'll call the native function. And the last one is the native function that we'll call the debugger functions that already existed in our runtime. So it will decode the message buffer following the STB protocol and do what needs to be done. Now you might be curious to see what happens when it hits to a breakpoint, which is the inverse path. So again, the links and the snippets. It's executed when the runtime hits a breakpoint and calls this native function. Then it calls this JavaScript function that contains this debugger statement. And here is the trick. This debugger statement makes our proxy receive via CDP message like the debugger positive. Then we receive this debugger positive message. And then we call this another method, which will check what kind of, which will decode the message in STB format. And we'll check what kind of pause we received if we need information like cost, allocations and et cetera. And so it sends the message to runtime to ask for these informations in the same way that I explained it to set a breakpoint using the runtime evaluate message. A question that you might be asking, is it possible to support debugging in other browsers? The answer is yes, we can follow the same idea to support debugging in any other browser that has remote debugging feature. We already have an experimental support for Firefox and this is the extension that we use when we want to debug from VS Code. Here, a curiosity, recently our runtime is supporting mode thread and we had to change some things to make the debugger work. If anyone wants to once can look at this PR, it's not merged yet. I hope it will merge it. Now, we can see a video, debugging a WASM browser app, which is an experimental template we created in .NET 7. So we will run, we will start edge listening on remote debugging port 90222 and we will use in the launch.json file the port of our proxy. Then we will attach, the breakpoint is already there. So we will click the button and you can see it's posted in the breakpoint. You can see locals and also cost stack. Now let's talk about the debugger in the WASM environment or WebAssembly running outside the browser. It was really quick to implement because we already had the debugger listening on socket because we already used it for mobile devices and we were able to reuse a lot of it. We already had a VS code extension that knows how to talk to the runtime and these extensions uses this another library which has all the logic to communicate using SDB. Here is the PR where we implemented the debugger for WASM. I think we have mostly two challenges. The first one was to pre-open a socket in the WASM environment and use it in our runtime. It was a little bit too difficult to understand how to make it work, but we could make it. So, and here is the link where we did it. And the second challenge is that our debugger uses an exclusive thread for communication the way that was implemented before and there isn't support for mode thread in the WASM environment. So, we had to communicate with the debugger on the same thread of the execution. That is whenever we find a sequence point we see if there is something in the communication buffer like setting a breakpoint and then we execute it. Also, when it stops at a breakpoint we're keeping out in this communication loop receiving and sending messages about costa, locals, watches and to receive ISEP or a resume and then it continues the execution. Here is a video debugging in VS Code a C-Sharp program running in WASI and for that we use the mono extension for VS Code and the link is here. So, we are attaching and we can resume, look at variables and also call stack. And here on the last slide I show you all the possible configurations to debug C-Sharp running on edge, Firefox and WASMI time without the browser. The first and the second configurations uses proxy. So, we set the part where the proxy is listening and the third configurations uses a socket that communicates directly with runtime. So, we use the part where the WASMI time has the pre-open socket. And what they have in common is that the three of them uses STP that means that on runtime side the code executed is practically the same for the three configurations. That's all folks. Thank you very much for the opportunity. Thank you very much for listening. And if you have any question, I am available. Thank you, bye-bye.