-
Tools we use: installing GDB for ARM
In this mini article, I’ll be going on a few strategies and nuances around getting a copy of GDB installed for debugging ARM chips.
-
Dealing with Large Symbol Files
Large applications can produce very large symbol files when debug information is enabled (especially at the higher, more verbose levels of debug info!). This article describes some techniques for reducing debug symbol file sizes!
-
Nash's Four Favorite Firmware Debug Tools
by Nash ReillyFirmware is an essential part of every modern electronic system. Try as we might to achieve perfection in our firmware, things will, inevitably, start to act funny. And when they do, it’s time for debugging! While a poor craftsman chooses to blame his tools, proper tooling can speed you to a robust diagnosis and an expeditious fix. Here are four of my favorite friends for finding and fixing firmware flaws.
-
Pocket article: Undefined Behavior Sanitizer Trap on Error
This post is a brief overview on how the Undefined Behavior Sanitizer can be used to trap unintentional or error prone parts of a C program. We’re going to look at how it’s used on a desktop program, as well as a way to use it in small embedded programs!
-
Share Your Debugging Scripts
In this short-form post, I want to share how you can go about keeping a central
gdbinit
file that you can commit into your project’s repo and automatically source it in the popular editor and IDE environments that firmware engineers find themselves in today. -
Advanced GDB Usage
In this reference-style post, we discuss some of the more advanced and powerful commands of the GNU debugger, GDB, as well as cover some of the best practices and hacks I’ve found over the years that help make GDB more pleasant to use.
-
Faster Debugging with Watchpoints
In this post we will explore how to save time debugging by making the most of watchpoints. We will walk through a few classic use cases of watchpoints by debugging an example application with GDB. Then, we will dive into how watchpoints are implemented for ARM Cortex-M based MCUs with the Data Watchpoint & Trace (DWT) unit and explore some advanced features.
-
Step-through debugging with no debugger on Cortex-M
This week we explore how to debug running systems with ARM Cortex-M’s DebugMonitor exception handler. We cover how to configure the MCU to operate in this mode and walk through an example of installing breakpoints and single-stepping on a running device!
-
How do breakpoints even work?
In this article, we will discuss the basic types of breakpoints (hardware and software) and how they are utilized by the GNU Project Debugger, GDB. We will then explore how to configure hardware breakpoints on an ARM Cortex-M MCU using the Flash Patch and Breakpoint Unit (FPB) and examine a real-world configuration with an example application.
-
gdbundle - GDB and LLDB's Missing Plugin Manager
GDB and LLDB desperately need a way for developers to share scripts, user-interface improvements, and utilities with their peers. This would enable building upon existing work and debugging techniques, progressing the entire community and preventing developers from reinventing the wheel. GDB and LLDB need a plugin manager, and I’d like to introduce to you gdbundle.
-
Using Python PyPi Packages within GDB/LLDB
In a previous post, we discussed how to automate some of the more tedious parts of debugging firmware using Python in GDB Scripts. To make these commands more powerful, one could use third-party packages from Python’s PyPi repository. In this post, we will discuss how to properly setup GDB, Python, and optionally virtualenv and then modify the
uuid_list_dump
command from the post mentioned above to make use of a third party package installed through PyPi. -
Automate Debugging with GDB Python API
Previously we discussed how a significant portion of developer time is spent debugging firmware and how GDB can be a powerful utility for this. In this article we will discuss how to become more efficient at debugging by leveraging GDB’s Python API.
-
Debugging Firmware with GDB
If I had to choose one significant aspect that I was not aware of before starting my career as a firmware developer, it would be how much time is spent not actually developing, and instead debugging firmware!