Debugging native code on a platform can be done using Eclipse by following these nine steps:
Step No. 1: Start the target. Using Eclipse, start debugging the Java application (or service) containing your native code. Stop the Java-side debugger in the entry point of the Activity or Service.
Step No. 2: Using the Android plug-in in Eclipse (or adb logcat), determine the Linux process ID for the application/service.
Step No. 3: Configure the machine to port forward to the target by executing:
~> adb forward tcp:10000 tcp:10000
Run gdbserver on the target, attaching it to the process ID found above (PID below):
~> adb shell /system/bin/gdbserver tcp:10000 --attach PID
Step No. 4: In Eclipse, go back to C/C++ or Java mode, but do not disconnect the Java debugger if you want to debug the Java side as well.
Step No. 5: Select your C/C++ project, right-click and select Debug Configurations.
Step No. 6: Select the Android C/C++ debug configuration you made earlier and click Debug. Eclipse will connect to the emulator and bring up the Debug perspective filled with target information, along with the remote Java debug information. It is normal to see warnings from gdb about dynamic sections. Ignore them. You can switch between the Java and C/C++ debug sessions as needed, though Java debugging will be unavailable while halted in native code.
Step No. 7: Select the C/C++ target in the Debug perspective, and click Suspend to stop the native process to see the current call stack. Examine each thread within the process and find which one is executing the DBG_HALT() in your code.
Step No. 8: Look at the disassembly of the DBG_HALT() code to find the memory location on the stack where it is pulling the value of "i." Change the memory location 1.
Step No. 9: Changing the memory location prevents you from single-stepping. To work around this, set a breakpoint at the next valid C/C++ line of code after the macro and click Resume. The breakpoint will get hit immediately and the ability to single step through the code.
Android platform and native development documentation may be sparse, but source code access and an understanding of how to set up your native code projects for debugging should give you a head start.
Larry Schiefer is a Senior Software Architect at Bsquare Corporation. He is the lead engineer in its Android engineering practice and has worked on Android projects for several Bsquare customers. Most recently, he led the effort to port Adobe Mobile Client (AMC) software to an Android-based handset. Larry also has managed embedded system software development with Linux, Symbian, Windows Mobile and Windows Embedded CE operating systems. His project experience covers 802.11 driver ports/enhancements, WiMax, Gigabit Ethernet, custom application-specific integrated circuit (ASIC) firmware, BSP development and custom GUI applications. Larry has a BS degree in Computer Engineering from Rose-Hulman Institute of Technology in Terre Haute, Indiana. He can be reached at LarrySC@bsquare.com.