I have created various static libraries (.a) with NDK. I have them linked in and working. How can I set breakpoints in the source code for those libraries? I opened one library using a regular VS project file but no breakpoint was hit. I assume that maybe this is because I opened it as a regular VS project.
hi stuggy,
you could make mit by adding additional library symbols Directories and Additional GDB Directoies at project Property>Debugging Page.
victor
Thanks for the info. I did this but breakpoints are not hit.
This is a static library that I built using NDK from the command line. In Visual Studio for windows apps I am used to including the project for the library and then breakpoints are hit. In this case I have a project for Windows for that library and included it in my solution but the breakpoints don’t get hit.
I added in the symbol directories and additional gdb directories but nothing happens when I set a breakpoint.
Hi Stuggy,
Was that library built on the same machine? GDB doesn’t really play nice with different source paths on a build server and a debugging machine. Does the library contain debugging symbols?
Yes it was built on the same machine. As far as debugging symbols that is a good question. I am not sure of the answer. What is the build flag using NDK? I think I read something about that. I’ll have to do some searching.
In the meantime what about my question of getting a break point to hit. Let’s say I don’t have a project for the library in VS should I be able to just open a source file and set a breakpoint and it will be hit?
I rebuilt my library with NDK_DEBUG=1 as a command line option to try and ensure that I have symbols but still no joy in getting a breakpoint hit.
The following did work for me:
- Create a new Hello World Demo project.
- In HelloJni.c add #include <first.h> to the includes and int x = first(12, 34); before return in the only function there.
- Set a breakpoint at the added code line.
- Add \samples\two-libs\jni to C/C++ → General → Additional Include Directories.
- Add \samples\two-libs\obj\local\armeabi to Linker → General → Additional Include Directories.
- Add twolib-first to Linker → Input → Additional Dependencies.
- Run “…..\ndk-build NDK_DEBUG=1” in the \samples\two-libs folder
- Build and debug in VS.
- When the breakpoint is hit, step into the “first” function.
In my case, the two-libs’s first.c file is opened automatically by the Visual Studio and I can see the code, locals/autos, etc.
If all this works for you, but your case doesn’t, could you please create a minimal repro sample for us? We’ll gladly fix the issue if it is on our side.
It is confusing. I can’t say what the problem is.
I had 2 NDK built libraries.
For the first small NDK built library I decided to also create a static library project using Nsight and then breakpoints work. The second much more involved library that I have added the same way as far as paths etc but the breakpoints are not hit. I’m not sure what to do and probably will keep struggling with it. It is a bit too involved to create a test case. So it seems to be something in my setup if the simple NDK library worked for you.
In your point 5 I assume you meant library directories.
I just tried your example and it worked with the adjustment to point 5.
In VS 2010 I had to include the full path on the library under step 6 and the .a extension. The additional library path in step 5 didn’t appear to help in finding the library.
I still don’t know yet why mine doesn’t work.
I made some progress but more questions.
It looks like the problem might be related to my definition of where the source files are in my Android.mk.
My source files are outside of the jni directory. I like to do out of source (svn etc) builds.
LOCAL_SRC_FILES := $(LOCAL_PATH)/…/…/source/first.cpp
for example seems to create a problem when debugging.
If I copy all source files to the jni directory and then strip off the prepended path then the breakpiint is hit when debugging. Interestingly it built using NDK both ways but only debugs when stripped.
Am I doing something not acceptable? How do people maintain source outside of the build directory structure?
That’s basically what I meant - GDB is very picky when it comes to resolving paths. We have a workaround in the docs which might help in your case:
[url]NVIDIA GameWorks Documentation
If you are using ndk-build.cmd, there is an extra “/” in the command line which is sent to the compiler and prevents breakpoints from being hit. To work around this issue, modify your Android.mk file from:
LOCAL_PATH := $(call my-dir)
to:
LOCAL_PATH := $(subst //,/,$(call my-dir)
Have you tried running objdump -Wl on your binary? Are the paths well-formed?
Regarding your last question - it seems that most people we know either use Nsight Tegra to build their libraries from within the Visual Studio or fill in the Debugging → Additional GDB directories appropriately.
Thanks for the extra info I will investigate.