Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No support for debugging library projects #13

Closed
DoDoENT opened this issue Mar 14, 2016 · 7 comments
Closed

No support for debugging library projects #13

DoDoENT opened this issue Mar 14, 2016 · 7 comments
Assignees
Milestone

Comments

@DoDoENT
Copy link

DoDoENT commented Mar 14, 2016

In r10, I could run ndk-gdb --package=my.app.package to debug native code inside android library from test app.

In r11, ndk-gdb bash script has been removed and ndk-gdb.py does not support that. Please add this feature back.

@DoDoENT
Copy link
Author

DoDoENT commented Mar 14, 2016

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)

@DanAlbert DanAlbert modified the milestones: r11b, r12 Mar 14, 2016
@DanAlbert
Copy link
Member

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.

@DoDoENT
Copy link
Author

DoDoENT commented Mar 15, 2016

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.

@jmgao
Copy link
Contributor

jmgao commented Mar 29, 2016

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)

@DoDoENT
Copy link
Author

DoDoENT commented Mar 29, 2016

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.

DanAlbert pushed a commit that referenced this issue Apr 16, 2016
This is useful for library projects.

Bug: #13
Change-Id: I000997de803ebfdf55ebdb89d868f4300a6902b4
(cherry picked from commit 1d20400)
DanAlbert pushed a commit that referenced this issue Apr 16, 2016
This is useful for library projects.

Bug: #13
Change-Id: I000997de803ebfdf55ebdb89d868f4300a6902b4
@DanAlbert
Copy link
Member

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

@DoDoENT
Copy link
Author

DoDoENT commented Apr 26, 2016

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

@DoDoENT DoDoENT closed this as completed Apr 26, 2016
@PvR33 PvR33 mentioned this issue Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants