My IoT Product Journey
Things I Learned Today
- How to build CMake projects in debug
- How to more effectively debug with gdb
- That gdb doesn't entirely work on the current version of OSX Sierra
- Some nano editor keyboard shortcuts
Some days Maker IoT is more glamorous than others. Today was a not so glamorous day spent debugging an issue in Remote Wiring. Here are the notes from the day.
How to Build CMake Projects in Debug
cmake -DCMAKE_BUILD_TYPE=Debug ..
GDB Debugging Notes
- Pass command line args after starting gdb using run command
- bt for backtrace and backtrace full to show variables for all stack frames
- p [variable] to print a variable while at a breakpoint or halt
- s or step to step next instruction
- info locals to list local variables while in a function
- info args to list the value of arguments passed to a function
-
break can take several forms to create a breakpoint
- break Classname::function-name
- break line-number
- break filename:line-number
- break filename:function
- help if you need...well, you get it
GDB on OSX Sierra
I spent close to an hour trying to get gdb working on my Mac. After going through quite the process of creating a certificate and code signing gdb and multiple brew install/uninstalls I found that dynamic library debugging is currently broken. I did learn a bunch about how to get gdb running on Mac though. Here are the most informative links I found.
- http://stackoverflow.com/questions/39702871/gdb-kind-of-doesnt-work-on-macos-sierra
- https://sourceware.org/bugzilla/show_bug.cgi?id=20981
Nano Shortcuts on Pi
- Ctrl-w - search for a string
- Ctrl-_ - go to a line number
- Esc is the meta key
- Esc-w - repeat the last search
Thought of the Day
Me: "So which line of code is blowing up?"
Other Person: "Well I've done this and this and that and tried X, Y, and Z"
Me: "Which line does it blow up on?"
Other Person: "I don't understand."
This is a classic debugging problem that so many people struggle with. They start spinning their wheels about all of the different things they've tried and done and speculate on what the issue might be. But this is coding. At the end of the day if your program is crashing spectacularly it comes down to a single line of code. Find that line of code and you start to find your problem. It's such a simple concept yet hard for many people to grasp. Get your code into a debugging environment and start stepping through it and putting breakpoints in. Eventually you will find that one line of code that when you hit the "Step" command on to proceed to the next instruction the whole thing goes nuclear. Now it's just a matter of working your way backward to see WHY it blows up on that line.
It's not always fun but digging into code this way can teach you so many things. Today I got to learn more about gdb, its current shortcomings on Mac OSX Sierra, how to build in debug with CMake as well as how to edit files more effectively on the Raspberry Pi using nano. Beats just guessing and hoping somebody else will figure it out.
