Eclipse+cdt+gdb Debugging Android NDK Program

Eclipse+cdt+gdb Debugging Android NDK Program

First introduce the development environment, in this environment, the UP master guarantee is no problem.

1. Ubuntu 11.10
2. Eclipse 3.7 (Indego) for Java
3. JDK 6
4. Android SDK 2.2
5. Andrid NDK R7

Of course, in the Windows environment through the Cygwin and other tools can also be implemented GDB debugging, I have indeed implemented. But the performance is too low, the card can not be used at all. Debugging The local method directly with GDB under Linux is smooth.

Once you've decided to install and configure your development environment, you're ready to start.

First you have to make sure that you can run a NDK project, even if the operation is a problem, there is no debugging.

To create a new Android project, select Crete Project form existing source, where the source code is located

/home/shaodx/android/android-ndk-r7/samples/hello-jni, which is the samples/hello-jni of the NDK directory.

Next>

The SDK Target chose 2.2, and the others, though not tested, should be fine.

Finsh

Hellojni project is extremely simple, see the code to understand. Create a TextView under Activitie, and then call a Natvie method to return a string, and then set the text of the TextView to this string.

To make it easier to see the effects of debugging and changes in local variables, I added a few lines of code that didn't affect the program results.

Java code:

C++:

Of course, this time, the program will definitely crash. Because the dynamic link library is not compiled yet. The ndk-build in the NDK root directory is responsible for compiling so files. First go to the directory where the project is located, then run Ndk-build.

The effect is as follows:

Something went wrong .....

The Host ' awk ' tool is outdated.

The following solutions are available after Internet search:

Find this awk,file in the/home/shaodx/android/android-ndk-r7/prebuilt/linux-x86/bin/directory:

This awk file is actually a 64-bit version of it, no wonder that it was expired. (Google programmers are careless.)

The solution was to just delete this awk ... and it would be all right .....

After solving the problem, change your posture and try again.

The so file exists in libs/armeabi/libhello-jni.so.

Now it's time to run the program.

But it would be too much trouble to call Ndk-build every time the C + + code was modified. Introduce a method for once and for all.

First, install a cdt,eclipse>help>install new software for Eclipse

To http://download.eclipse.org/tools/cdt/releases/indigo/

Anyway, I have installed all the options, and it won't take much time.

Then the installation Sequoyah address is http://download.eclipse.org/sequoyah/updates/2.0/

This will only need to install Sequoyah Android Native Code support.

Then convert the current project to a C + + project.

File>new>other:

Convert to a C + + Project

Set as shown in the figure:

Finish.

At this point, the C + + code in the project is also recognized. Generally this time will be a lot of errors, mainly GCC can not find the jni.h header file, also can not recognize some of the functions and data types from JNI:

It is necessary to add an environment variable to GCC to find jni.h, and the environment variable name is C_include_path. This name is not writable, and the environment variable under Windows is called include.

Then refresh the project a few more times and the errors disappear.

Next, compile the C + + code for the configuration.

Enter the project properties page, and Build command is set to the full path of the NDK under Ndk-build.

Replace all of the builds at the behavior Options page with a space

The next step is to run directly, and the C + + code is automatically compiled into so files each time it is run. At the same time, it is convenient to write Java code and C + + code in Eclipse.

The downward work is really related to debugging.

First go to the engineering directory and run the NDK-GDB under the NDK directory. When you perform this step, you should ensure that the emulator is running. If someone is more accustomed to the imperative method of debugging the program, you can directly use this NDK-GDB to debug the program. The next step is to graphically debug this gdb.

Under Eclipse, enter the Debug>debug configuration and select the C/ Android-ndk-r7/samples/hello-jni/obj/local/armeabi/app_process, this file is designed for debugging and exists, if found to find this file, it should be run first ndk-gdb. Only running ndk-build will not produce this file. Project selects the current HELLOJNI.

The bottom process launcher select other selects Stuanard

Then go to the Debugger tab, Stop on startup at is filling in the C + + program entry function, this project is Java_com_example_hellojni_hellojni_stringfromjni, I think this parameter should be of no use, remember to set the breakpoint on the line. GDB Debugger is: home/shaodx/android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/ ARM-LINUX-ANDROIDEABI-GDB, this path has a lot of files for other platforms, do not choose the wrong. Gdb command file is/home/shaodx/android/android-ndk-r7/samples/hello-jni/obj/local/armeabi/ Gdb2.setup, the current Gdb2.setup file does not exist yet and will be created later. The bottom verbose console mode must be remembered so that you can interact with GDB with instructions in the Eclipse console.

Enter the connection subkey for debugger options, type TCP, Port 5039:

After Setup is complete, apply.

The next step is to modify only two files. Remember to back up before modifying

The first is ndk-gdb, the bottom line "$GDBCLIENT-X ' Native_path $GDBSETUP '" directly removed, save.

Then copy the Gdb.setup in the '/home/shaodx/android/android-ndk-r7/samples/hello-jni/obj/local/armeabi ' directory, named Gdb2.setup. Open the Gdb2.setup, remove the last line of "Target remote:5039", Do not think to modify the Gdb.setup, and then the previous settings point to Gdb.setup will work, because each time the call Ndk-gdb, will produce a new gdb.setup to overwrite the changes.

Then you can set a breakpoint on the code, first remember to have a breakpoint before calling the local method, and then set one.

C + + code sets a breakpoint at the entrance to the function.

The following is the beginning of the formal debugging, first run the project's Java debugging. The program will then run to stop at the first breakpoint.

At this point, run to the project directory under the command line and run the ndk-gdb under the NDK root directory.

There is no output after the run.

Then start Debug for C + +, which is the previously configured JNI Debug.

As the C + + program also set a breakpoint, continue to press F6 can be directly executed into the C + + program.

A big picture, familiar with Eclipse debugging is no pressure. The value of the local variable can be seen directly in the upper right corner, including the parameters passed in.

At the same time, can communicate directly with GDB in the console, to exit the C + + program debugging, continue can, the program back to the Java code:

Transferred from: http://www.cnblogs.com/shadox/archive/2011/12/02/2272564.html

Eclipse+cdt+gdb Debugging Android NDK program (GO)