# Debugging Code With GDB and Valgrind

For this project, I followed the GDB [instructions](https://bootlin.com/doc/training/debugging/debugging-labs.pdf) from [Bootlin](https://bootlin.com/) and used Valgrind on one of my programs from my High-Performance Computing class.

## Intro to GDB and Valgrind

### GDB

[GDB](https://sourceware.org/gdb/) is a full-featured and open-source debugger. It is integrated into VSCode and given a very pretty front end.

It is possible to remote debug with VSCode and GDB, but often many embedded development environments run it in its natural form on the terminal.

### Valgrind

[Valgrind](https://valgrind.org/) opposed to GDB is a runtime tool. It analyses the stack, heap and disassembly of the program to primarily find and report memory leaks.

It can be used for much more, including cache usage and miss reports, deadlocks and race conditions, and heap memory usage.

## GDB

### Packages

I had to enable some settings in the buildroot menu for GDB to be present and working on the board:

* BR2\_PACKAGE\_HOST\_GDB, in Toolchain | Build cross gdb for the host
    
* BR2\_PACKAGE\_GDB, in Target packages | Debugging, profiling and benchmark | gdb
    
* BR2\_PACKAGE\_GDB\_SERVER, in Target packages | Debugging, profiling and benchmark | gdbserver
    
* BR2\_ENABLE\_DEBUG, in Build options | build packages with debugging symbols
    
    * This one specifically builds the included C libraries with debugging symbols.
        

### Running the Code

In order to connect to the board, and run gdb remotely, we need to run this command on the board:

```bash
gdbserver --multi :2000 ./linked_list
```

Which outputs:

```bash
Process ./linked_list created; pid = 168
Listening on port 2000
```

and then start gdb on our pc

```bash
gdb
```

Which when running, looks like:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684950587/6be9c0e1-1586-4e8f-b81b-27266322869b.png align="center")

To connect to the board we need to run:

```bash
target extended-remote 192.168.1.100:2000
```

Where the IP address is that of the board, and the port 2000, is what we told GDB to use.

### Compiling and Placing On board

We should compile this program using the cross-compiler provided by buildroot. It is found in `output/host/bin/arm-none-linux-gnueabihf-gcc` and we can add this to our PATH to make it easier and faster to compile our programs.

We need to do this because buildroot doesn't include a compiler when it builds the images. It is intended for final products mostly.

We can compile on our machine and sftp it over with:

```bash
sftp root@192.168.1.100
```

### Debugging

The most basic commands for GDB are:

1. `run` - starts the execution of the program being debugged.
    
2. `break` - sets a breakpoint at a specified location in the program.
    
3. `step` - executes the current line and stops at the next line in the source code.
    
4. `next` - executes the current line and stops at the next line, but does not enter function calls.
    
5. `continue` - resumes execution until the next breakpoint or until the program terminates.
    
6. `print` - prints the value of a specified variable or expression.
    
7. `backtrace` or `bt` - prints the stack trace of the program at the current point of execution.
    
8. `list` - displays the source code around the current point of execution.
    
9. `info` - displays various types of information about the program being debugged, such as registers, breakpoints, and threads.
    
10. `quit` - exits GDB.
    

we can use this to trace along our program like in vscode

I'll set a breakpoint at the 'main' function with `b main`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684937781/6fb809f3-1395-4021-a713-9690d55fd75e.png align="center")

and run the program, stepping with `next`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684931833/76259062-4596-4498-8c58-0ca5ed857c95.png align="center")

You can see that this follows along the code file that we have:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684911326/23731cb7-8764-479e-b120-0161de93fcd9.png align="center")

GDB also has a nice Text-User-Interface, or TUI that you can enter with Ctrl-X-A

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684916610/bffaa1c0-18b1-4e53-9dc7-1861d91922f6.png align="center")

Let's try out a few of these commands:

We can set breakpoints with 'b' and see them with the info command:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684899803/1691f30e-a530-4670-89e7-29538e30f946.png align="center")

And delete them with 'delete'

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1681684888568/6a93b950-a3db-4acf-9266-275cb69cb13b.png align="center")

There are many more commands, and gdb is one of those tools that can take time to master. This was just a simple lab, however.

## Valgrind

I ran valgrind on a program I wrote in High-Performance Computing. This was a hastily poorly written program with little care for memory cleanup so I knew it would be leaky.

There isn't much to it. You can see output from valgrind with a summary of any memory leaks by running:

```bash
valgrind --leak-check=full ./program
```

Below is what is outputted (concatenated because it's super long):

```bash
==7144== Memcheck, a memory error detector

==7144== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.

==7144== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info

==7144== Command: mpirun -np 4 ./halo

==7144==

...

==7144==

==7144== LEAK SUMMARY:

==7144== definitely lost: 6,705 bytes in 24 blocks

==7144== indirectly lost: 31,491 bytes in 465 blocks

==7144== possibly lost: 0 bytes in 0 blocks

==7144== still reachable: 829 bytes in 21 blocks

==7144== suppressed: 0 bytes in 0 blocks

==7144== Reachable blocks (those to which a pointer was found) are not shown.

==7144== To see them, rerun with: --leak-check=full --show-leak-kinds=all

==7144==

==7144== For lists of detected and suppressed errors, rerun with: -s

==7144== ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
```

As you can see, there are quite a few leaks in this program. It's run with MPI, and I didn't take into great consideration the cleaning up of the memory.