How do you debug embedded software that runs on multiple cores or threads with gdb?

Assuming we would be debugging in an IDE(w.r.t. the microcontroller): - Open Terminal and choose the option to debug the program using gdb. Or type in : gcc -g -o yourProgramObjectFileName yourProgram.c - Run your program using r. - keep a breakpoint at any line/ the line you suspect at. - type in: info threads - this is list all the threads running on your device. - type in: thread <thread number given in the above list> - This would switch to that thread. -Set breakpoint of a particular thread by typing in: break <location of that thread> thread <threadNumber> - Watch the variables in it by typing in: watch <theVariableYouWantToWatch> thread <threadNumber> - Continue running the execution by: continue - view registers using: registers

What is GDB? GDB (GNU Debugger) is a tool used by programmers to find and fix errors in their software. Imagine you’re writing a program, but it’s not working as expected. GDB helps you “pause” the program, see what’s going wrong, and fix it step by step. Here’s how it works: Breakpoints: You can stop the program at specific points. Inspect Variables: You can look inside your program’s variables to check their values. Step through code: Run your program line by line to see how it behaves. Track errors: GDB helps identify the exact spot where things go wrong. In essence, GDB is a powerful magnifying glass for programmers, making it easier to troubleshoot and improve their code.

To debug embedded software on multiple cores or threads with GDB, start by compiling the code with the `-g` flag for debugging information. Connect to the target using `target remote`. To handle multiple threads, use `info threads` to list them and `thread <thread-number>` to switch between them. For multi-core debugging, we will often need a JTAG debugger that supports multiple cores, along with OpenOCD to manage GDB server connections. You can set breakpoints, step through code, and inspect variables for each thread or core. To debug multiple cores, you can open multiple GDB sessions, each attached to a different core.

GDB is the GNU Debugger, and it’s my go-to tool for stepping through code, setting breakpoints, and inspecting the state of my embedded system. It works really well when I’m dealing with low-level code or need fine-grained control over the debugging process. I’ve found it particularly useful in debugging complex, real-time systems where timing and concurrency are critical. Using this kind of tool only I learned a core knowledge about embedded systems

Debugging multi-core systems or multi-threaded applications adds complexity, but GDB supports this with specific commands. I use the "info threads" command to list all the active threads, and "thread <ID>" to switch between them. If I’m working with multiple cores, I’ll often need to target specific cores using processor-specific commands. For example, in a project using FreeRTOS, I had multiple threads running on separate cores. I had to switch between thread contexts to find where one core was stuck in a loop, while another core was executing fine. GDB made it easier to see what each core was doing in real-time.

Debugging code on multiple cores with fine control of halt-resume sequence sometimes can be challenging. Use GDB is a good way to start. Alternatively, consider capturing trace which is a non-intrusive way to observe concurrent behaviors on multiple cores.

I rely on a few key GDB commands. "break" to set breakpoints, "continue" to resume execution, and "step" or "next" to step through code. But when dealing with threads, "info threads" and "thread apply" become essential. I can apply a command like "bt" (backtrace) to all threads at once to see where each thread is in the code. In a real case, I had a system crash where one thread was causing a deadlock while holding a mutex. GDB helped me identify the problematic thread by applying a backtrace to all threads and analyzing the call stack.