1) In Eclipse open your Android project which contains C/C++ code that you want to debug.

For this tutorial I’ve created simple MyAndroidProject.

2) Set android:debuggable=”true”. Set android:targetSdkVersion=”9″.

android:debuggable is a property of <application> tag in your AndroidManifest.xml. You can set it either directly in xml or in Application tab as in the screenshot.

android:targetSdkVersion=”9″ is a property of <uses-sdk> tag in your AndroidManifest.xml. You can set it either directly in xml or in Manifest tab as in the screenshot.

3) Run your application in debug mode and try to run ndk-gdb from console

To run application in debug mode press debug button (green bug/spider button in toolbox). In console go to your project directory and run ndk-gdb. It should succeed. If it fails you have to resolve the problem. Running ndk-gdb does not only ensure us that we are doing everything right so far, but also creates app_process, gdb.setup and libc.so files in obj/local/armeabi/ subdirectory of our project. Those files will be needed in later steps.

4) Create C/C++ debug configuration

Click on combo-box like down arrow next to debug button. Pop-up menu will appear and then select Debug Configurations…

In Debug Configurations window select C/C++ Application and press New button as advised on the right pane.

5) Set name of the debug configuration, and fill information on Main tab.

Select Standard Create Process Launcher by clicking on the blue Select other… link at the bottom of the window.

In C/C++ Application entry fill the path to the app_process binary which is located in obj/local/armeabi/ subdirectory of your project.

6) Click on Debugger tab and fill information about debugger.

Choose gdbserver Debugger as a Debugger.

It’s good idea to set initial breakpoint to some function but Android projects do not contain main function so fill some appropriate function name in Stop on startup field (I filled Java_com_example_map_MyAndroidProject_doSomething but you can see only Java_com_exam on the screenshot).

Set path to GDB debugger. The debugger is distributed with the Android ndk. Its located at toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb.

Set path to GDB command line. This path should point to obj/local/armeabi/gdb2.setup file inside your project. You don’t have gdb2.setup file there yet but you will create one in a while.

7) Click on the Connection tab (so you are in Debugger->Connection section of your C/C++ debug configuration) and fill information about connecting gdb with gdbserver.

This will save your new C/C++ debug configuration. Later, when running your application in debug mode you can choose in combo box associated with Debug button what debug configuration you want to use. Now you have two debug configurations. Android Java one which was created automatically for you when you’ve created Android project. And C/C++ one you’ve just created.

9) Go to the obj/local/armeabi/ subdirectory of your project and copy gdb.setup file to gdb2.setup file. Remove target remote :5039 line from gdb2.setup.

Eclipse don’t like target remote :5039 line in gdb setup file because it wants to enter this command internally (that is why you configured port 5039 in the previous step). Because the gdb.setup file is recreated by ndk scripts you have to copy it to the gdb2.setup and point Eclipse to the gdb2.setup file (we did this in step 6).

10) Go to the directory with Android ndk and copy ndk-gdb to ndk-gdb-eclipse. Remove execution of gdb command from ndk-gdb-eclipse.

Eclipse will run the gdb binary itself. So we have to remove the execution of gdb from ndk-gdb. To save original content it is good idea to copy the ndk-gdb to ndk-gdb-eclipse.

11) Now you are done. Put breakpoint in Java code after the execution of System.loadLibrary() and start your application in Debug mode.

Start your application in debug mode by clicking on Debug button. It will automatically choose Android debug mode. Later you will have to take care to choose Android Java debugging configuration by clicking on combo arrow associated with the debug button.

The reason that breakpoint should be after System.loadLibrary() call is that our C/C++ code will be already loaded in that point and we can set breakpoints in it.

12) When execution reach the breakpoint run ndk-gdb-eclipse from your project directory and start debugging in C/C++ debug mode.

Go to the directory with your project and run ndk-gdb-eclipse. This will start server-part of the debugging infrastructure. Now click on the combo arrow associated with the debug button in Eclipse and choose Debug Configurations… Choose your C/C++ debug configuration and click Debug button.

The C/C++ debug configuration will be added to recently used debug configurations so later you don’t have to walk into the Debug Configurations… window again and you can choose between Android Java debug configuration and C/C++ debug configuration by just clicking on the combo arrow associated with debug button in Eclipse. However always make sure which debug configuration you are about to execute as this is where mistakes happen very often (at least for me).

After you’ve started C/C++ debug configuration click Resume button (or press F8). The application should resume its run and stop on C/C++ breakpoint (if you have one).

13) Now you are debugging the C/C++ code. Have fun!

Try to set some breakpoints in C/C++ code, etc.

Note on running ndk-gdb-eclipse

You have to run ndk-gdb-eclipse every time before starting C/C++ debug session. This script starts the gdbserver binary on device/emulator so gdb (run by Eclipse) can connect to it.

I made several attempts to force Eclipse to run ndk-gdb-eclipse script itself on start of C/C++ debug session. The most logical point is to write small script which will run ndk-gdb-eclipse without parameters (or with –force parameter) and then run gdb from Android ndk toolchain with all the parameters. This script can be used as GDB debugger command in the Debugger tab. But even if this script (and ndk-gdb-eclipse inside) was run successfully, the resulting connection of gdb and gdbserver always broke apart.

80 Responses to Using Eclipse for Android C/C++ Debugging

I have tried following these instructions to debug one of the NDK example projects. However it seems to want a C/C++ project for the debug configuration and I am unclear how to set this up within the existing sample directory. There is no option for creating a project from existing source for a C/C++ project as there is for an Android project.

first of all thank you very much for your posts.
i’m running from mac and i have one problem though: i don’t have the app_process, maybe because i’m deploying directly o a device? i’m trying to debug the OpenGL sample app that came with the Android NDK r6, which cannot run on the emulator.

Hi. Great tutorial but I run in into the same issue as Graham did.
When I try to start the native debugging eclipse moans that this is not a C/C++ project.
Do I need to convert the whole project to a CDT project ?
Thanks for any hints,
Claus

I’m confused about the exact sequence of events needed to hit a C++ breakpoint. I think I need eclipse to start the gdbserver itself on the emulator, meanwhile pausing execution until it connects…then resuming execution.

The prescribed method seems to be setting a java breakpoint after the LoadLibrary call of the C lib, then opening a separate terminal and running ndk-gdb to start the server, then resuming in eclipse, but that seems ridiculous and slow for C development.

I had a few more steps to get close to the same results, and fails in fine… In my case, gdb refuses to recognize the symbols and has no effect, though it gets connected properly…

1) First of all, I had to add “LOCAL_CFLAGS := -Wall -g” in the project “jni/Android.mk” (btw this way I finally got C/C++ compilation warnings at last)

2) Then, I had to comment out the line “$(hide) $(call cmd-strip, $(PRIVATE_DST))” in the “build/core/build-binary.mk” NDK installation folder, because it was stripping all the symbols from the the resulting JNI shared lib anyway (I spent some time on this one…)

3) I do not understand why I have a different folder setup. May be I misconfigured my project, but my “app_process” is located in “./obj/local/armeabi-v7a/app_process” and not in “./obj/local/armeabi/app_process” as the rest of the world… I set up the other folders accordingly then, but I am somehowe unsure, especially since I fail to get the gas plant work at the end ;)

4) Anyway, I can get Eclipse to connect to the debugger with the usual procedure (start Java debug with a breakpoint in System.loadLibrary, then ndk-gdb-eclipse, and finally start C++ debug.
However almost every time, it complains and fails to load the symbols though. OK, I can tell it via gdb “file” option (just provide the path to the .so file). Then I can set/disables breakpoints in the C++ source, but they really have no effect. If I pause the C++ execution, then the Java side gets frozen, but I cannot do much more then continue execution.

I’m getting out of ideas to have it work properly, may be some of you would have some nice advice of experience with these issues?

Thanks for your help, you probably are pointing in the right direction since the symbols are not loaded by default. I’m not sure what is the app_process that gets pulled from the device (it has np symbols btw). So I added an explicit “file obj/local/armeabi-v7a/myproject.so” in gdb2.setup, even though I guess Eclipse does or should usually do this on its own (I found nobody talking about this).

ndk-gdb-eclipse –verbose tells me this though: “Using gdb setup init: /home/jeremie/workspace/smartgrappe/libs/armeabi-v7a/gdb.setup”, it seems to conflict with gdb2.setup as specified in eclipse. But may be it’s meaningless at this stage b/c the deal is first to get the gdb server up and ready if I understand.

OK so the debugger really gets connected (as seen in adb logcat for example), and I start the C/C++ debugging configuration from Eclipse after having started the Java debug and breaked on System.loadLibrary.
The eclipse debug console dumps a warning though:
94-target-select remote localhost:5039
&”warning: shared library handler failed to enable breakpoint\n”

However it continues, dumps some thread infos (where symbols and line numbers are OK). Then it gets very slow dumping information about current breakpoints (~2sec per line), and finally pops up a dialog telling me “Target is not responding”, which locks in turn all the session including java debugging. No way to continue at all.

Here is the end of the debug console in eclipse. At line 75+ it slows down to a halt. I entered none of the commands btw.

Hi,
One more issue from my side: After I ran the GDB first time I changed a lot of function names.
As well native functions wher I had set breakpoints. But now when I try to start the native part of the
app, eclipse refers still to the old function names.

I assume that this is cached somewhere, but I did not find the cache location, yet.
If someone has a hint on this …

Trying to get it working, unfortunately when I launch the debug configuration of the C/C++ app I get a ton of errors like
“Error while mapping shared library sections:
libstdc++.so: No such file or directory”,

I first tried to debug my C++ Lib using __android_log_vprint(), but I quickly realized a real debugger would be a lot better …

I searched for hours, tried several other procedures without success until I found and followed your procedure… it took me some time as:
– some paths were different (“app_process” is located in “./obj/local/armeabi-v7a/app_process” and not in “./obj/local/armeabi/app_process” like Jim above)
– the environment variable ANDROID_NDK_ROOT was not set on my system,
– I did not select gdbserver in the C++ debug configuration (and as a result there was no connection tab with the port 5039 setting).
– I was using stlport_static without running build/core/build-stlport.sh, and this produced warning messages that crashed the ndk-gdb and ndk-gdb-eclipse scripts (took me a long time to figure out this one!)

How did you figure out that you had warning messages that were causing crashes? How exactly do you run ‘build/core/build-stlport.sh’ (I think you mean build/tools/build-stlport.sh)? I tried to run it and got errors. Is putting the following lines in my Application.mk the same:
APP_STL := stlport_static
STLPORT_FORCE_REBUILD := true
?

great guide — there’s no way in hell i would have figured out how to do that without this page – thanks. I did have to do some of the extras in some of the comments. #1 & 2 from Jim above
– LOCAL_CFLAGS := -Wall -g
– comment out the line “$(hide) $(call cmd-strip, $(PRIVATE_DST))” in the “build/core/build-binary.mk” NDK installation folder
– added the extra paths though i’m not sure i needed to
– build/core/build-stlport.sh since I’m using static stl – this was huge, as without doing it, the warning messages were piped into the next thing, in ndk_gdb script, thereby screwing the pooch.

it is too bad that somehow ndk_gdb_exclipse can’t be made to run automatically, but i’m sure some eclipse expert out there will figure it out finally.

Dear all,
I have done all the setups and also followed the others who have commented about the post…
I get the following error finally

Error while mapping shared library sections:
/system/bin/linker: No such file or directory.
Error while mapping shared library sections:
libstdc++.so: No such file or directory.
……. and so on..
I understand i need to link few libraries but am not clear about the steps ???
Kindly guide.. any steps or pointers would be of great help…

Hi,
Is it also possible to do native debugging when using an external jar that has native components ?
I have split my application into a pure Java application and an API project that has now the native stuff and just generates the *.jar and the *.so files. So i have no app_process file which I need to have in the debug configuration.
Someone ever tried this ?
Thanks,
Claus

I couldn’t get this to work at all. Would be nice if this was updated to newer versions of Eclipse, since none of these screen shots look like the Eclipse I am using. Also the location of the gdb.setup is not the same either.

Thanks for the tutorial. I found it difficult to get going, and even now while I think it works as expected in HelloJNI, it has odd segfaults and extreme slowness that have me unsure.

I want to highlight what I found most difficult, as I think other people have had the same problem with the instructions here and at sequoyah:

I was stuck wondering what was causing debug not to start, with message “connection refused” etc. My failure was not reading the instructions here precisely enough, making a few false assumptions.
The steps 11 & 12 need to be reread a few times to realize – they tell you after setting up this new debug configuration and scripts etc –
1. Start the Normal-Java-Android debug config, that is used for debugging java code, and stop that on a breakpoint
2. then, run ndk-gdb-eclipse from the shell, (it runs for me with no output normally)
3. only then, start the new android native debug configuration that we’ve been instructed to make
4. After it seems to be running, continue the debug session in the normal java mode, such that breakpoints in native code should now be hit

I think the steps are obvious once you recognize them, but when I was just trying to blindly follow steps I was missing what was actually been said, and I think other people were too.

I followed the steps and the comments on NDK r7b with Eclipse Indigo Windows 7 64-bit. It works on one of my project, but failed on my other project. Additional step I have to do is to uncheck the “Use full file path to set the breakpoints” checkbox in “Debugger” tab, I guess this is only needed for Windows operating system.

Thank you for this tutorial as well as the previous tutorial “Using Eclipse for Android C/C++ Development”. Both were very helpful.

After getting everything working (I think!), I was wondering about “Note on running ndk-gdb-eclipse”, so I thought I would try a slightly different approach, which seems to be working – at least on the version of Eclipse I am running (Indigo SR2) on a Mac.

1. I made a new external tool to run ndk-gdb-eclipse: Run->External Tools->External Tools Configuration. Select Program, click “New”. Name: ndk-gdb-eclipse (or whatever you like), Location: (absolute path to ndk-gdb-eclipse – the script we made), Working Directory: (set to project directory), Arguments: –adb=(absolute path to adb).
2. I made a new Launch Group to run the external tool and my C++ debug configuration: Run->Debug Configurations, select Launch Group, click “New”. Rename it to whatever you want. Click add, select “run” in Launch Mode dropdown, pick Programs->ndk-gdb-eclipse (or whatever you named it). Click add, select “debug” in Launch Mode dropdown, pick C/C++ Application->”MyAndroidProject C and CPP Debug” (or whatever you named your C++ debug config).
3. That’s all. Follow all the other steps, but when you get to step 12 launch your new Launch Group.

Hi, I followed the post to the letter and got the same problems as mentioned above. The debugger can’t find the library. I saw that the “file” option of the gdb was mentioned. I saw in the gdb2.setup that such command already exists which tell the gdb where to find app_process and I added another line almost identical with the lib file. Now it is impossible to debug the application since it complains that the file does not exists, even that it appears at the same directory as app_process.

file obj/local/armeabi/app_process
file obj/local/armeabi/libhello-jni.so
———————————————————
anyone can see the problem? (The only thing I thought of is that the library is deleted in the clean process and created after the gdb attempt to use it, but it doesn’t make much sense)

Uhh… my app targets API 8 (Android 2.2). Why do you say we should use android:targetSdkVersion=”9″? API 9 isn’t listed in SDK Manager (just API 8 and API 10=Android 2.3.3). I am also curious what android:debuggable=”true” does, given that Java debugging works without that attribute.

Hmm, looks like I have to give up on this Eclipse debugging idea. After converting the project to C++, my program always crashes on startup! I can’t even reach step 3. LogCat spits out a whole lot of nonsense, I think the most relevant line is “signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 80b3d454”

It’s a good thing I was modifying a backup copy of the project! Another weird thing is that after restarting Eclipse (Indigo), the C/C++ options are no longer accessible (the two C/C++ sections are missing from Project Properties). I retried the conversion a second time, with the same results (both times, the C/C++ options disappear after restarting.)

Thanks for the tutorial, would never have got this to work without it.
I did get the error “no symbol table is loaded” when running the c/c++ debugging, fixed it by editing the gdb2.setup file. Changed the line “(path-to-ndk-folder)/platforms/android-14/arch-arm/usr/include (path-to-ndk-folder)/sources/cxx-stl/system/include jni”
to
“(path-to-ndk-folder)/platforms/android-9/arch-arm/usr/include (path-to-ndk-folder)/sources/cxx-stl/system/include jni”

Can u give me a link to your tutorial in which i can debug the both j2me and c++ code simultaneously,as i am making a jar file of c++ code and adding it to the my j2me code,i want to debug both code simultaneously

Hi Martin thanks for your post…
In my case Everything OK as you said other than the last step. First I ran the gdb server from my project root directory by the command “ndk-gdb-eclipse” and it is exiting without any error. But when I start debugging on c/c++ mode from the eclipse, I am getting the error like

I tried this on windows 64 bit (without and it works with some adjustments to paths.
1. There is no app_process of windows. you need to get it from device and put it in libs folder yourself.
2. The gdb.setup file does not need any changes.
3. In my case, i had to edit the ndk-gdb.py file myself as it has wrong paths for utility executables( C:\Development\NDK\prebuilt\windows-x86_64 instead of C:\Development\NDK\prebuilt\windows) i essentially renamed the folder as per needs of the script.
4. comment out last lines in ndk-gdb.py file.
# gdbargs = [GDBCLIENT, ‘-x’, ‘%s’ % (GDBSETUP)]
# if OPTION_TUI:
# gdbhelp = subprocess.check_output([GDBCLIENT, ‘–help’]).decode(‘ascii’)
# try:
# gdbhelp.index(‘–tui’)
# gdbargs.append(‘–tui’)
# OPTION_TUI = ‘running’
# except:
# print(‘Warning: Disabled tui mode as %s does not support it’ % (os.path.basename(GDBCLIENT)))
# subprocess.call(gdbargs)

WARNING: no debugging symbols found in C:\Development\adt-bundle-windows-x86\android-ndk-r8d\workspace\Sample1\obj\local\armeabi\app_process.
Either the binary was compiled without debugging information
or the debugging information was removed (e.g., with strip or strip -g).
Debugger capabilities will be very limited.
For further information: http://wiki/Main/GdbFaq#No_debugging_symbols_found

warning: Could not load shared library symbols for 77 libraries, e.g. libstdc++.so.
Use the “info sharedlibrary” command to see the complete listing.
Do you need “set solib-search-path” or “set sysroot”?

Thanks for this tutorial. I followed it exactly and it worked for me first time on a device. I have not started using it over and over as I do development, yet. I got depressed around step 10 thinking “I have to do this every time? How will I remember?” If anyone figures out how to automate the launching of adb-gdb-eclipse that would be excellent. I may try the launch config described by Tony (May 29, 2012 at 21:52), it’s a little closer to automation.

There is NO WARRANTY, to the extent permitted by law. Type “show copying” and “show warranty” for details. This GDB was configured as “–host=x86_64-apple-darwin –target=arm-linux-android”. For bug reporting instructions, please see: . Warning: /Users/eladb/MyWorkspace/Client/src/android/java/src/pcf: No such file or directory. Remote debugging from host 225.89.3.0 warning: while parsing target library list (at line 2): No segment defined for ..

Thank you for any other informative blog. The place else could I get that kind of information written in such an ideal way?
I’ve a challenge that I’m just now running on, and I have been on the
look out for such info.

I seldom comment, however i did a few searching and wound up here Using
Eclipse for Android C/C++ Debugging | Android blog.
And I do have a few questions for you if it’s allright. Could it be simply me or does it look like some of these remarks appear like written by brain dead individuals? :-P And, if you are writing on additional online social sites, I’d like to keep up with
everything fresh you have to post. Would you list of every one of your community sites like your
Facebook page, twitter feed, or linkedin profile?