 Hi, I'm Mark Goodner, a Program Manager on the Visual Studio C++ team. In this video, I'm going to show you the Visual Studio GDB Debugger extension. To use this extension, you need to have Visual Studio 2015 community or higher with the Visual C++ tools for Android or iOS installed. Those tools use the open source MI engine that provides the support for the Visual Studio Debugger to use machine interface that GDB and LLDB use. The GDB Debugger extension introduces a new project type that surfaces additional project properties that allow you to connect the Visual Studio Debugger to GDB either locally or remotely, including on remote Linux targets. I have four demos to show you on how to use the new GDB Debugger extension. We'll cover GDB project creation, local GDB debugging, GDB debugging on an Azure Linux VM, and finally GDB debugging on a Raspberry Pi with Azure IoT Hubs. Now, let's take a look at those demos. I'm going to quickly show you the new project template that the GDB Debugger extension adds. After you've installed the extension, create a new project and you'll find a new template under Visual C++ cross-platform for Make File Project GDB. So when we create that, we get an empty solution file that has some resource files that we use for adding properties to the project and there's a readme file that covers extensively how to set up SSH, remote connections, how to create the certificates that you need to use on the Linux side and how to use the project properties we add in all of your build scripts. So let's take a quick look at the project properties. You'll see that under the Debugging tab, that we've added options for a remote GDB and for local GDB connections and we're going to cover those options in more detail in the subsequent demos. So let's quickly cover how to use this with a local GDB Debugger on Windows. For this demo, we've already got a working MinGW environment that's minimalist GNU for Windows and that provides us with the GNU Compilers, GCC, G++ and the GDB Debugger that we'll use here. If you're interested in this, you probably already have some code, so we'll show you how to get started that way. So we'll browse to where our code already is and we'll go ahead and select that folder and then we'll just give our project a name here and we won't create a directory for the solution. And now we'll add an existing item to import our source. Alright, we'll take a quick look at that source and what we'll do here is we'll add a couple of breakpoints just so that we can see how this works. Let's go to our project properties and get this set up. So we'll go to the Debugging tab and we'll switch over to local GDB and we'll set our working directory to where we're at and we'll give the executable a name. We don't have any executable arguments for this one and the local Debugger executable is GDB, so that's fine. The local Debugger server address is used if you need a port for GDB. We don't need any of that here, so we're okay. We'll go ahead and apply those project properties so that we can see how that works within the build command line. So edit the build command line here. And what we've got here is we're using G++ to compile our code. We're using the properties from the GDB Debugger tab for the local working directory, specifying our source file. We're telling it to emit our debugger symbols and then we're using those parameters again to use our working directory and our executable and you can see how all of that is interpreted there. So if we apply all of that and you see our local GDB executable is specified here so we can go ahead and hit F5. We don't know whether or not the project has been built or not so we're always going to prompt you with this but in this case we do need to go ahead and build it so we're going to say yes. The build starts and there we go. We've hit our first breakpoint. And if I hit F5 then I continue to the next breakpoint. You'll see that peak works. I can see and set a watch point. And as I continue to execute you'll see that the watch value changes. I can remove my watch point and I can come back through and I can set another breakpoint and continue and I hit... I can remove breakpoints and continue through. And so that's GDB working locally on Windows. Okay, so what about Linux? Let's change the project we just saw to call remotely to an Azure VM. And here you can see I've got an Azure VM that's running Linux. This one happens to be running Ubuntu. So let's go ahead and grab that server address. The only real requirement we have on the Linux VM is that it has SSH set up. You need to use certificate auth in order to connect to the machine. We're not going to cover setting that up. That's covered in all the Azure documentation. It's also covered within our readme file. But we'll go into the remote GDB tab and we'll change that to put in the host name from my Azure VM there. Give it my username. And we'll give it the private key that we need to use to connect. And in this case I'm going to be using putty. You can use any other SSH client including from MinGW or the PowerShell open source windows port. In this case I'm using putty. And so for this I need to use the plink tool. plink is the non-interactive shell version of putty. And so now I need to specify my remote working directory. So if we quickly swap over and use a saved session here to connect to that Azure VM. What I can do is I can change over to where I want my source to be and print my working directory. And you can see that there's nothing in this directory right now. We'll give it the remote executable name that we want on the remote machine. Again we don't need any remote executable arguments. The remote debugger executable is GDB and that's fine. So now we're going to change our build command line. So for a build command line this time what we need to do is we need to actually copy our files across to the remote machine and then build them. So we've applied our changes so that we can see how this gets evaluated. And basically what we're doing is we're using the project properties to specify the private key, the Linux username, the host name, the remote working directory, etc. And you can see that this is flexible in the sense that I'm using the putty tools for PSCP to copy the files over and that connects to the remote machine, puts them in the file, the folder where I want them at and then P-Link actually just executes and runs the commands that I need in order to compile the source on the other side. So now that I have all of that I can come through, I can hit F5 project is out of date, build it, yes. And so what you can see is when the project starts it's actually copying the file across and then it runs G++ on the remote Linux target and you can see I hit my breakpoint as before and if I come through I can set a new breakpoint, I can continue executing, I can step through my code and you can see that I've got the same sort of peak experience that I would normally expect from a breakpoint that I can continue executing. It's just everything that I would expect from within Visual Studio and I can actually come back over to the Linux machine now and you can see that my files are there and I can actually execute this executable there directly. All right. For my final demo I'm going to show you debugging code from on a Raspberry Pi that's connected to the Azure IoT hubs. For this we have a breadboard that's wired up with the Pi with some LEDs and buttons to show some of the hardware interaction when a button is pressed and LED lights up and a message is sent to the Azure IoT hub and then we can also receive messages from the Azure IoT hubs that will light in an LED. For this one I've configured the Pi using Somba so that I can mount the remote file system as a local drive and that way I don't have to copy files back and forth. So loading the solution off of the Pi we can take a look at the source file here and you notice that we've specified headers from the Azure IoT SDK and from wiring Pi and that's going to give me access to the GPIO pins and if I navigate down to the main function you'll see the IntelliSense actually works the way that we would expect it to and that's and that's because I've already set up my project properties to refer to where all of those SDKs are on the local Pi so if I go into VC++ you can see that under the include directories I've actually specified the directories on the Pi and these directories are just GitHub repos that I've synced down locally on the Pi which is available there and then by specifying them there I'm able to actually get IntelliSense working within this project. So let's take a quick look at the debugging tab and see what's different here. It's largely the same as any other Linux machine you'll see that I've got my remote host name I've got my username and I've specified my private key and this one instead of using PuTTY though I'm using the PowerShell OpenSSH port to Windows and so you could also use MinGW it doesn't matter we support all three of those options I've got my remote working directory set up there what my executable is but you notice on the remote debugger executable that rather than just saying GDB I'm saying pseudo GDB and that's because within working with the wiring Pi APIs that those need brute access in order to access the GPIO pins and so I actually have the flexibility to specify launching GDB slightly differently than I normally would in order to accomplish that and so if we take a look at the make file or at the make command in this case we're still using the project properties in order to do things but in this case all I'm doing is I'm not copying any files and that's because I'm already working with the files directly so all I'm using is SSH to pipe over the commands from the MI engine in order to build and execute the remote executable alright so let's F5 we'll go ahead and let this build we're always going to get this illegal instruction to download the symbols for a crypto API that we need so this is safe to ignore so we're just going to go ahead and continue we can see the debugger is ready and using the device explorer from the Azure SDK we can monitor and see that I'm actually getting messages as they press a button on the device and if I press the left button you'll see that I actually trigger and fall into the debugger and so now I can actually step through my code, I can hit F11 and actually continue stepping through code and you see now that I'm actually in the IoT hub SDK so I can actually step all the way down through into the other code that I've told Visual Studio where it is and so I can continue and let things run again and now if I come back over to the device explorer I can grab a message to send back to the device but the machine just broke so we'll grab our message here and restart it so now what we can do is actually send a message to the device from the device explorer so I'll send a message and you see now I've popped into Visual Studio again at another break point that I've set and as I step through my code here we can actually see the LEDs on the board light up and then we can let it continue again that's all I have to show you for today this is our first release and we need your feedback on what is working for you and what isn't we hope to hear from those of you who are building cross-platform apps services running on big Linux servers and of course everyone with devices that I hope you're connecting to Azure IoT hubs we hope to release regularly and we're working on enabling this with local GDB servers and interface with on-chip debuggers as well for even smaller device targets if that's of interest to you please get in touch with us through the VC++ team blog and thanks for watching