 Hi, I'm Alexandra. I work in Red Hat in a debugger team. And I'll tell you, why do you want to use Valgrind and GDB together? And what I've done to make it easier. So I'll be talking about GDB, about Valgrind, and about how to use them together. I think it's not well known that you can connect to Valgrind from inside GDB and ask Valgrind about things. So before some new features came to Valgrind, you used to need two terminals. So you would run Valgrind at one terminal, you would run GDB at other terminal, and you connect them together using VGDB. I've wrote an article about how to do that, and what advantages it may have. Also, I'd like to talk a bit about debugging 4D. So GDB as a debugger is interactive. You'll run your program and your GDB, you can stop it, you can inspect variables, and so on. But Valgrind is not. When you are running a program under Valgrind, you can change anything on the fly, and Valgrind will give you some diagnostics at the end. But when using Valgrind and GDB together, it's different. So Valgrind has GDB server embedded in it, and when running GDB, you can connect to Valgrind, and then Valgrind will have any problem with your code. For example, invalid write happens. There is conditional jump dependent on initialized value or anything. Valgrind will stop GDB. It will stop running your program. And at this point, you can send some comments to Valgrind. You can ask Valgrind about if this variable defined or not, for example. Current Valgrind release brings several new features which makes connecting to Valgrind easier. With VGDB multi-mode, you don't need to use two terminals to connect to Valgrind anymore. Now you can run GDB, and you can run Valgrind from inside GDB. And the other new features is Valgrind Python script, which allows you to ask Valgrind about things in a very convenient way. Both of them are already in Fedora38, and they work out of the box together with Debug InfoD. I'd like to say a few words about Debug InfoD. Debug InfoD is HTTP-based server which contains Debug Info packages, and various debugging tools can fetch them from there automatically. On Fedora38, it's enabled by default, and Valgrind will automatically fetch any missing Debug Info packages. And GDB will ask you whether you want to do that. In some cases, when you have a lot of Debug Info packages missing, this might take a lot of time. So it might be inconvenient for you. So Aaron Mary is working on demand downloading. So a few words about VGDB multimode. So first of all, what's VGDB? VGDB means Valgrind to GDB. And it's a small tool which serves as an intermediary between Valgrind and GDB. Valgrind GDB server starts only with the program. So we need VGDB to set up some initial communication. For doing that, we are using GDB's remote protocol. So GDB using the remote protocol will communicate with VGDB and pass arguments to it, and then VGDB will launch Valgrind. Why do you want to use this? One thing, you don't need two terminals to communicate with Valgrind anymore. You'll run GDB, and you can launch Valgrind from it. And other advantages it brings, you can keep your breakpoints. You have GDB history. This simplifies scripting a lot. But this feature is slightly experimental, and it has some limitations I want to talk about. So one of the limitations of this is that VGDB communication uses standard input and standard output, which means that your debug program can't read from standard input and can't output. So standard in and out is pretty much being eaten by GDB, VGDB communication. You can avoid this by running VGDB in a separate terminal and connecting them using ports. But this makes things more complicated, and yeah, it makes things more complicated, but you still have the advantages by you can still keep breakpoints, GDB history, and so on. I'm working on addressing this. I'm trying to redirect GDB, GDB server communication in general to use sockets instead of standard input and standard output. Other limitation of this feature is you can run Valgrind from inside GDB, but it's not that simple yet. You need to perform some preparational steps. We are working on implementing target Valgrind, which would hide all the preparational steps, and it will make it easier to just run Valgrind. I also, I forgot to say, this VGDB multi feature was designed by Mark VLR, and I co-worked with him on implementing it. So how to actually run Valgrind from inside GDB? First of all, you just run GDB as usual. Then you need to do these preparational steps. You need to set remote exec file to your debug program, then because this is, so the remote protocol or GDB, GDB server communication, it thinks that it's some remote debugging, but we are doing things locally, so we need to set this route to slash, and this command, this target extended remote pipe, VGDB, is the command that will launch Valgrind. Here you can see VRX. Those are arguments passed to Valgrind. Here we are using quiet, because we don't want Valgrind to talk too much. If you want to debug your program repeatedly, if you want to run the command repeatedly, you can do all the preparational steps in one command using GDB's X command. And as I told before, we are working on target Valgrind, which should be, I don't know, I think it will be soon, it will be here soon. So the next feature, which was written or implemented by Philippe Barroquer, to is Python extension for monitor commands. So monitor commands is, monitor commands is the way how to communicate with GDB server. There's a special request, GDB sends to GDB server, and GDB server responds to them. There is no further integrations, it's just a text. Valgrind has GDB server, which is embedded, and Valgrind has a specific set of its own monitor commands, and this feature allows better integration. So it brings help, so before this, you had to look up what are the commands, but now you can type help Valgrind, and GDB will tell you which commands are possible. Also, there is auto-completion, so GDB will automatically complete the command, and you don't have to remember it. You can search even before the command, and what I think the best is GDB will evaluate the command arguments. The thing is, so you have some undefined variable, for example, and you want to inspect it. You want to ask Valgrind if this defined, and before this feature, you had, because Valgrind doesn't know anything about variables. It only knows about addresses. So you had to ask GDB to evaluate the address of the variable for you, and then you would feed that to the monitor command, but now GDB will evaluate any argument for you, which is very convenient. So how it looks like in the real life, so you'll run GDB and some program. Then you will perform the preparational steps. So you'll set the remote exec file, you set C through to slash, and then you'll use this command to run Valgrind. With some arguments, you can use other arguments, of course. Like you can specify Valgrind tool to use, for example, like tool call green, for example, or anything else. Then you can set a break point in this point or anything you want to do is GDB. You can see here that Valgrind script was, Valgrind monitor script was loaded. It is only loaded when Valgrind's GDB server is used. Also, you can see here, you can type help Valgrind, and let's do that. So if you'll type help Valgrind, GDB will list possible Valgrind tools you can use. Note that Memcheck is default tool for Valgrind, but you can use any else. So Memcheck deals with memory issues, and Valgrind, it deals with threading, for example. But Valgrind has a bunch of other tools. So here you can see that if you can get specific help for any of the tool, and it will list a list of comments that it's possible to use. Another interesting thing that this Python extension brings is an option to change Valgrind option dynamically. So when you normally run Valgrind, you'll set some options, and you can change them on the fly. But when Valgrind is connected to GDB, you will stop at some point. For example, you set the breakpoint, and you can add or change some options. You can add verbose. You can set traces calls to yes or any other option. So now I want to show how you may use monitor comments. So for example, the other thing I want to show is that you continue in GDB, and then you get interrupted by Valgrind, and its output is interleaved with GDB's output. So here Valgrind says there is a conditional jump or move dependent on uninitialized value. And here this six-trap signal is a signal generated by Valgrind to stop your program. And GDB will output the line of the code where Valgrind has problems. So there are two flags here, and one of them is uninitialized. And to determine which of them is uninitialized, we can use memcheck get babitz comment. Here you can see that we can feed memcheck this, and this Python script will evaluate the address of this variable. So get vbits knows which bit is defined and which is not, and all ones refers to undefined, and zeros refers to defined. So this flag is undefined. So it's the one which was uninitialized. Another interesting memcheck comment is who points at, it will list your references to some pointers, so if you think that pointer might be leaked, it can help you. Another interesting Valgrind feature is stop at exit. So normally when your program will end, Valgrind will shut down, but you can ask it to stop at exit. So stop, and at this point, you can use some monitor commands. I don't have an example of this leak, sorry. So here I ask memcheck if there is any memory leak and Valgrind says no, everything was leaked. So for summary, using Valgrind and GDP together might be incredibly useful, but it used to be a bit tricky to set up. You need to know about how to set up to terminals, and also I think not many people even know it's possible. But with those new feature Valgrind brings in the current release, it's much, much, much simpler. But there are some problems we are working on addressing. Here I'm linking my work in progress. I'm trying to redirect GDP-GBD server communication when GDP server is run locally and using standard input-standard output to sockets. And also I wrote some articles about how to use Valgrind and GDP together. I have a code example here with intentional bugs there. And I'm giving an examples of various commands, various monitor commands. Also I have a personal blog and sometimes I would blog about my project there. Also I'd like to thank all the people that made Valgrind and GDP closer. So Aaron Mary is helping implementing debug info desupport for Valgrind and GDP. Philip Varokir is the author of Python monitor commands. And also he was the one who integrated GDP server into Valgrind. Mark Villar designed the GDP multi-mode and we worked on it together. And Andrew Burgess is helping me with my standard out to socket redirection on GDP side. Thank you for listening. Questions? I'll ask questions right in the room or via feel free to ask anything. Please, the audio main. Just say a question and Alexandra will repeat it into the microphone. Okay, then I will make it short. So Valgrind is a simulator, right? And basically the program gets translated into some byte codes. I think it's called you code, right? And say Valgrind. So my question is, when you are debugging a program using this mode, do you still have access like to a step instruction, you know? Yes. To the assembly code and your program, like if you was debugging it there, you know? So yeah, I have to repeat your question. So when debugging, when connected to Valgrind, do we still have access to step, to GDP step? Do you still see your program? Yes. Like transparently? Yes, yes. The only thing that you can see is your program output that it outputs to standard output. Yes, but other than that, it might contain some bugs because it's completely new feature. You might try it and you may find bugs, but stepping should be possible. Okay, so the question is, is it possible to pass both Valgrind and GDP to GCC? I wasn't aware of this feature, so I haven't tried. So sorry, I'll try. Thank you for the question. Yes. So I have to say that I haven't used Valgrind myself. I was using Memcheck when developing this. So I don't know, I would have to try. Is that this technology specific to risk performance development? Can this be adapted to microcontrollers? I mean, you can use GDB with microcontrollers. You can use the GDB server. So if there is Valgrind, there could be a lot of it. Sure, like if you have enough memory to install Valgrind, I can see no reason why it won't work, but I haven't tried on microcontrollers myself. But it should work. You try. Great, thank you. I am going. Yes, Gwyn. I can sometimes see something like, a write was happened after Memorial Scree. If the program stops at that point, can we, from GDB, ask Valgrind to create like when the memory was created or when it was allocated? Is there a way to ask that information? Yeah, I'm not sure at this point, sorry. I would have to look up documentation. Can you repeat the question? Yeah, so the question was, if there was, if Valgrind stopped because there was using all the memory after free, so how exactly we would ask Valgrind using memory monitor commands to tell us? I'm not sure. So I don't know every monitor command from the top of my head. I would have to look up documentation. Yes? So thank you guys for there is a certain goal. Yeah, I haven't tried. So the question was, is it possible to integrate Valgrind with LLDB? And my answer is, I haven't tried. But I think it's an interesting thing to try. Thank you for the question. This one? Yes. Okay, so the question is, can we ask Valgrind to stop only at specific places? I think we would have to use suppression. So there is a suppression mechanism that you can use with Valgrind for those cases. Yes? Yes? I don't. Yes, yes, I think I would use suppression. Yeah, that sounds great. Maybe we should start working on that.