"Training a monkey would be easier"

If you’re more or less successful in your debugging session, it’s quite likely that you’ll have to modify some source code so you can actually fix a bug. And if you’re more or less careful, you might want to validate your changes actually work. We saw some time ago that you don’t need to restart gdb after a recompile because gdb is already smart enough to know that the binary changed.

Turns out you don’t even need to drop from gdb to a shell: just type make (using the parameters you’d usually call make with) and watch gdb take care of building your binary again.

Rebuilding your project like this is not only useful to save time: you can also keep your breakpoints and they should still make sense, assuming you didn’t refactor your code too much.

Raise your hand if you have run gdb in tui (graphical) mode, only to find you can’t refer to the previous command when pressing “up”. I can’t see you but I know this is true for pretty much everyone reading this blog. All three of you.

In the gdb-TUI mode, the arrow keys are used by the active window for scrolling. This means they are not available for readline, the component that takes care of the magic invocations needed to bring back the previous command from the land of the dead. Luckily there are alternative readline keybindings: just try C-p, C-n, C-b and C-f. Takes a while getting used to it but you can finally use gdb-TUI and forget about copy-pasting every gdb command.

I don’t know how good Android Studio support for native apps is nowadays (it changes from week to week!). Up to a few months ago, Gradle, the build system used by AS, had poor support for native development. If you’re having problems, you may find it easier to workaround it completely when it comes to build and debug C/C++ applications.

To debug a native Android application, a binary called gdbserver and its associated gdb.setup must be included in the generated APK file. Including this into the APK can be very painful in Gradle, so here’s a workaround I found:

Build your stuff the way you normally would (I’m assuming you know already how to build a native app, and if you don’t there are guides online that explain it much better than I could).

Crosscompiling is always fun. No matter how ready-to-use it’s packaged, and Android does a pretty decent job at that, you’re still bound to find problems that leak through the abstraction layers. If something says it’s dummy-proof, I always find the way to perfect myself and be even dumber. For people like me; do yourselves a favour and start launching ndk-gdb this way:

ndk-gdb --start --verbose

Using the –verbose parameter will probably reveal some hidden errors. For example, when I forgot to chmod 777 my gdbserver binary: