 Okay, so this is the final screencast number five for assignment zero probably won't do so many for future assignments But hopefully these are helpful. So the last thing I want to look out We've talked about we set up an environment of both the kernel We've poked around in the source tree a little bit and we've used get and finally we're going to get to Gdb. So what is Gdb? Gdb is the canoe debugger And this is another extremely again. This is not something we invented the canoe debuggers I've been a companion to the canoe compiler for a long time. So there's a gazillion pieces of documentation out there Now, you know, I just want to point out you don't have to use Gdb but You will want to You, you know, otherwise you will just be in a world of hurt There are ways to debug things without using Gdb and you may have gotten away with them in the past You've put printf statements in your code or you know, you've Just used that you're incredibly well-developed powers of deductive reasoning or something but But this is tough stuff, right? Particularly when you start to develop and debug multi-threaded code and code as complex interactions with other things You're gonna want to to have Gdb as part of your arsenal Okay, so, you know again a Gdb tutorial is kind of beyond the scope of what I'm trying to do I will show you a little bit about how to get started and get Gdb Running in your OS 161 environment. So I'm back in my root directory here. I can boot up a kernel. So I'm in good shape there However debugging using Gdb requires Two windows because I need to run my kernel in one window and interact with it and then connect with Gdb in the second window and that's because you actually need to debug the kernel and connect through a socket to the To this is 161 simulator. So here's I'm going to do that I'm going to use my handy T-Mux companion if you don't know T-Mux. It's an awesome tool. It's definitely worth learning So what T-Mux essentially allows me to do is to create multiple terminal windows switch between them here's window one and Here's window two and I have a really nice easy way you'll see down here at the bottom of the screen I've got a little display that's kind of handy tells me what's going on So T-Mux is a fantastic tool as you sort of start with the joys of Programming at the terminal and using the terminal All right, so now I've got I'm in my root directory. I need to run this is 161 Sorry the OS 161 debugger in the same directory where I run like kernel If you have poked around with this one to see when you'll see that it has this nice command line option now Currently assist 161 is set up so that any time there's a panic it will wait for a debugger before exiting So let me show you how that works. Let's fire up a kernel and let's panic on purpose All right, so now what you'll see I ran the panic shell Kernel command that just generates a panic now. What's happened is it's waiting for this debugger to connect Let's go over here Run OS 161 GB kernel Unix I'll explain what this is doing in a sec So I'm going to connect to the Debugger and then I can do a back choice and see what's going on and it turns out that this was generated by the command panic Which is part of the menu. Okay So that's what kind of what will happen If you generate a panic if the kernel panics and this will actually happen in any point It'll wait for the bugger connection. And now what I can do is just exit and I'm sorry quit. I'll let it shut down. It won't shut down until the debugger connects However, a lot of times you want the kernel not to start until there's a debugger connected So if you run this one 61 with the dash w option, that's what will happen Now this is the little piece of black magic that you need to connect to These this 161 debugger and this isn't super Black magic just let me kind of show you what's going on when system 161 runs It creates a couple of sockets in a dot sockets directory in that In the directory in which this one is running one of them is gdb That's how gdb Communicates with this 161 in order to control the kernel that you're running for debugging purposes there's also something called meter in there which is used to generate stats and Actually, if you run the stat 161 command, yeah, that actually connects to the meter device and pulse statistics about the kernel So it's running. Let me let me show you how that works. Let's run this Out that and then so this is that 161 output. It shows a little bit about what's going on But anyway, that's not what this tutorial is about 161 is fun, but we're here to use the debugger. So let's do that so now I'm waiting for my debugger and And what I do is I go to my other window Here's the way to invoke the debugger. I give it the kernel binary so that it knows something about the symbols that it needs to use and then I invoke this magic incantation which I Sort of suggest what this is telling it is to connect to a remote target It's a unique socket and it's in the sockets gd directory. So there we go. Okay, this is normal output when it starts up Gd can't always interpret all of the code that this 161 is using and But what I've done you can see that this 161 has accepted into debugger connection now Nothing is going to happen right because that the system is stopped. So but this gives me an opportunity to do certain things like for example Let's set a break point on the panic menu command Okay, so what I've done is I knew I had a particular command that I wanted the system to break when it Reached and now I've set a break point there. I know I'll continue. Alright, I Don't know why this is happening because it drops some characters. All right, let's try it now Break and panic Continue All right, there we go. Yeah, this is clearly a bug in since 161 and I will tell David about it All right, so now I'm at the menu and I can pretty much do the normal things I would do right Let me run the the one of the synchronization tests. Okay, that works Debugger still waiting right because I haven't run panic, but now okay system stopped and now I'm in command panic And it's useful to you know use gdb to kind of figure out what's going on with your system So one of these whole commands is L that shows me a little bit of context about the command that I ran And if I hit return, it'll sort of keep going and show me more So this is from you can see an in main menu dot see Line 253. So this is the panic command and you can see all it does is run panic, right? So let's step through it We'll do next right and That told it to go to the next break point, but at this point actually it did panic and so it got a sick trap And here I can produce a back phrase This shows every stack frame. So how did I get to this panic to this moment? Well, I started this is the boot sequence. I executed K main K main rather than menu the menu tried to execute a command This is a just a command dispatcher. That's part of the menu code that command was panic Panic executed the panic command and then I ended up by generating this L 3 stop, right? So what's interesting is I can go up right There's up Up up and what this does is it walks up and down the stack, right? So you can see here Here is in command dispatch This is essentially how the menu code maps between the string that I entered panic and the command that actually gets run I go down You'll see that that ended up in command panic. Let's go up One can't suddenly can't type So let's go up one more time. You can see this is essentially the main menu loop here, right? Let's let's let's list at 780 There we go. So this is you know the main menu that's being executed I put the kernel prompt I get a string and I try to execute it So this is a good way of sort of exploring what's going on in your system There's a great documentation for gdb online The only worries that I would point out is that gdb does the OS 161 gdb because it's debugging Through this socket that's provided by the system simulator does not necessarily Provide all the capabilities that you might be used to so for example I think watch points or something that doesn't work very well if not at all But you can set break points you can set through things you can set in and out of functions You can generate back traces. There's a lot of useful features here gdb Is a tremendously powerful tool for inspecting your running kernel and In comparison with printf another sort of declarative styles of debugging This sort of feature is extremely powerful and it's something that's worth learning because it will make it much much easier For you to find out what's going wrong when things aren't behaving as expected Okay, so that's the last of this one Hopefully you guys have enjoyed these and they've been useful in some way. Good luck with assignment zero