No support for debugging library projects about ndk HOT 7 CLOSED

I've created a patch that adds this functionality:

diff orig/ndk-gdb.py ndk-gdb.py
73a74,77
>         self.add_argument(
>             "--package", dest="package_name",
>             help="Specify package name of application that will be debugged")
> 
581c590,591
<     parse_manifest(args)
---
>     if args.package_name == None:
>         parse_manifest(args)

from ndk.

Actually, @jmgao thinks that patch will probably break some of the other use cases (I'll let him elaborate). Since you have a fix that you can apply locally, and he doesn't have time to look more closely right now (I'm hoping we get r11b out this week), I'm going to move this to r12.

from ndk.

OK, I am looking forward to @jmgao 's elaboration.

If omitting parsing of manifest may break some things, this can be written differently - in parse_manifest function one could skip extracting package name if it is already given via command line argument.

from ndk.

Sorry, had a backlog of other things that were on fire.

The patch as written doesn't disallow the use of --launch/--launch-activity with --package, which would fail because the manifest wouldn't have been parsed. I added it as an optional argument to --attach in this change, which should hopefully make it to r11c.

Out of curiosity, what does your project layout/build look like, and what are you mostly using ndk-gdb for? Would it be helpful for you if there were arguments to specify additional projects/directories to find libraries from? (e.g. something like ndk-gdb.py -p=/path/to/project --lib=/path/to/library/one --lib=/path/to/library/two)

from ndk.

Hi @jmgao!

Out of curiosity, what does your project layout/build look like, and what are you mostly using ndk-gdb for?

At MicroBlink, we develop SDK which performs camera management and real time camera image processing - mostly for decoding barcodes and performing OCR. So, we have a library project which contains camera management code and native wrapper. This library project has several flavours - one for each SDK we are offering. Each flavour has its own set of native build parameters (specific compiler flags and source file set) and its own java classes and resources. For each flavour we have a "test" app which we use to test camera management behaviour, scanning behaviour and overall performance. I've described our project layout in more detail in this blog post.

We use ndk-gdb primarily to debug native code from these test apps - as you can see, several apps with different package names all use the very same library module which contains native code. For that matter, we need support for debugging native code in library projects. We usually launch an app and then attach the debugger, so --launch option is not important for us.

Would it be helpful for you if there were arguments to specify additional projects/directories to find libraries from? (e.g. something like ndk-gdb.py -p=/path/to/project --lib=/path/to/library/one --lib=/path/to/library/two)

I am not sure. The reason for this is that we use Android Studio for development, and we use custom NDK build script as described here, i.e. in build/intermediates/ndk/flavour/buildType we create a small eclipse-like project so that ndk-build script is happy - we use the same folder to start the debug session. This folder contains only project.properties file. Besides that one, for each flavour-build type combination we also have a specific "debug" folder which contains symlinks to AndroidManifest.xml of specific flavor, to jni folder, and to all artifacts inside aforementioned build folder. From this folder we usually start the ndk-gdb session on compatible devices (unfortunately, ndk-gdb does not work with 64-bit devices, but this is another issue (#20)

I hope it is now clear why we need support for debugging of library projects.

from ndk.

This got added to r12, right? Can this be closed?

from ndk.

Actually r11c has got --attach option which solves this issue. This can be closed.

from ndk.