I'm trying to get the NDK debugger working but with no success so far.
To make sure my debug symbols are present and valid, I use the compiler options -O0 and -g, and the ndk-build parameter NDK_DEBUG=1.
The ndk-gdb script runs with out issues and launches GDB. When do a "sharedlibrary" command, I get this:
Symbols already loaded for /bla/bla/libMySharedLib.so
However when I try breaking execution or e.g. adding a segfault to test, I never get any of the symbols from that library in the call stack. The only symbols I've gotten are from libc, if I break execution while it's waiting for a mutex for instance. Also tried adding breakpoints with no luck. GDB lets me add the breakpoints, and the code runs fine, but the breakpoints are never triggered.
I'm using API level 8 as I need to support Android 2.2 (Froyo).
You don't need to use -O0 or -g switches.
You need to do one of following:
put android:debuggable="true" to the <application> tag in AndroidManifest.xml file
use NDK_DEBUG=1 after ndk-build
put APP_OPTIM := debug in Application.mk file
Doing anyone of these three things will automatically use -O0 and -g switches.
Can you try running gdb manually, without gdb script?
It involves following steps:
pushing gdbserver file to /data/local folder on device
running your application & invoking in adb shell following command gdbserver :5055 --attach PID, where PID is your application process id.
running adb forward tcp:5055 tcp:5055 on host
running arm-linux-androideabi-gdb.exe from your app folder
entering following commands in gdb
set solib-search-path obj/local/armeabi
file obj/local/armeabi/libMySharedLib.so
target remote :5055
And see if you can debug then.
If you want see symbols for other shared libraries your library is using like libc.so, then pull them from device (from /system/lib folder) to your obj/local/armeabi folder.
Related
I have an android application that consists of a Java based APK, native executable, and native library. The apk talks to the native (root NDK c/c++) executable and library over a socket.
I'm not sure if it matters but the executable and library are compiled via cmake, and copied to be executable and then run as root. I need to get some type of debugging going with breakpoints and such, regardless of if it's directly in android studio or via command line.
You would need to run gdbserver on the device and let it attach to your executable
gdbserver comes prebuilt with ndk, usually under <ndk>/prebuilt/android-arm/gdbserver/
Copy gdbserver binary to your device, for instance to /data/local/tmp and give it executable permissions with chmod
If your executable is already running, find its PID with ps command and attach gdb to it:
gdbserver :5039 --attach <PID>
Note that 5039 is port number that is usually used for debugging with gdb, you can use your own if you like
set up a port forwarding from device to pc with
adb forward tcp:5039 tcp:5039
Run gdb locally, note that you need arm targeted gdb that comes with ndk too, usually at
<ndk>toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gdb
Attach gdb to your process
target remote :5039
And from here you need to use gdb commands that match your debugging expectations (set breakpoints, load symbols, step through etc), for examples use cheatsheet or ask in comments
I'm using Terminal-IDE as my development environment. (Google code site here.)
I'm running Terminal-IDE v 2.02 - the very latest. My Android versions are:
Android 4.0.3
Software version 2.14.531.3 71ORD
(the rest aren't likely pertinent, but more on request)
I'm in a suitable development directory with a simple enough c source code file ready and run 'make'.
I have never yet gotten any compilation to work successfully. Most likely, there's a version mis-match with regard to what executable is available versus what the software is looking for.
Here's the command and error message:
terminal-gcc -c -Wall -I/data/data/com.spartacusrex.spartacuside/files/local/include tester.c -o tester.o
/data/data/com.spartacusrex.spartacuside/files/system/bin/terminal-gcc[43]: arm-eabi-gcc: not found
make: *** [tester.o] Error 127
Snafu, of course. I'm not at all sure how to find out what the right compiler file name(s) should be because, on this non-rooted phone, I don't have permissions to hunt through the PATH and find the actual executables.
It may also be that PATH is set wrong. All input appreciated.
...I'm not sure what's supposed to happen, but I found in the Terminal-IDE directory tree the file:
$IDESYSTEM/android-gcc-4.4.0.tar.gz
I also found that terminal-gcc is a bash script. Looking inside it seemed to say that a gcc tree should exist in "$HOME", which is the installation directory. So, I unzipped, then un-tarred the file identified above and put the resulting directory tree as a top-level subdirectory.
Well well, what do you know? Success.
I went a little further and created soft links to the actual compiler in ~/bin for both gcc and just cc, and suddenly all my previously created "Makefile" scripts used in other projects I wanted to move over started working perfectly.
Apparently, even though I thought I'd done it right, I overlooked running this script:
./system/bin/install_gcc
It extracts the tar, like I did, but does not create the links you may need.
Hey, if you're glad I got here before you, give it a thumbs up!
A credit goes to #Richard T for his enthusiasm regarding Terminal IDE. The answer is intended to enumerate the steps needed for running a C code.
To run a C code
Run Terminal IDE and extract the gcc package by executing
install_gcc
Create a directory for your projects within the Terminal IDE directory tree. Then in the directory create a source .c file with some code (filename.c here). Compile it
terminal-gcc -c filename.c
Create the executable file
terminal-gcc filename.o -o filename.out
Run the output file
./filename.out
If you'd like to use the PC (laptop) keyboard you can telnet Terminal IDE.
To Telnet Terminal IDE
From Terminal IDE start the telnetd deamon by executing
telnetd
Connect the Android device to the PC (laptop) and type
adb forward tcp:[port] tcp:8080
telnet 127.0.0.1 [port]
P.S. Telnet's default port is 23.
I am trying to attach the ndk-gdb to my Android application.
I am using is Android-ndk-r6b and device is Android 2.3,Samsung Galaxy S II.
I followed all the steps in this example Click here for the example
And also I tried with one application, when I am trying to attach gdb with another application but the verbose showing that it is always getting attached to the first application itself
Found package name: <1st attached package name>
I tried to launch the ndk-gdb using this command for the first time:
ndk-gdb --start --force --verbose
I tried to attach to another application with the below command but not able to succeed:
ndk-gdb --launch=com.example.hellogdbserver.HelloGdbServer --force --verbose
I am always getting the below error with first application:
ERROR: Non-debuggable application installed on the target device.Please re-install the debuggable version!
This is complete shell log which i am getting
sh-4.1$ ndk-gdb --verbose --start --force
Android NDK installation path: /cygdrive/c/Android/android-ndk
Using default adb command: /cygdrive/c/Android/android-sdk-windows/platform-tools/adb
ADB version found: Android Debug Bridge version 1.0.26
Using final ADB command: '/cygdrive/c/Android/android-sdk-windows/platform-tools/adb'
Using auto-detected project path: /cygdrive/d/EclipseTestWorkspace/hello-gdbserver
Found package name: com.example.hellogdbserver
ABIs targetted by application: armeabi
Device API Level: 10
Device CPU ABIs: armeabi-v7a armeabi
Compatible device ABI: armeabi
Found debuggable flag: true
Found device gdbserver: /data/data/com.example.hellogdbserver/lib/gdbserver
Using gdb setup init: /cygdrive/d/EclipseTestWorkspace/hello-gdbserver/libs/armeabi/gdb.setup
Using toolchain prefix: /cygdrive/c/Android/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-
Using app out directory: /cygdrive/d/EclipseTestWorkspace/hello-gdbserver/obj/local/armeabi
ERROR: Could not extract package's data directory. Are you sure that
your installed application is debuggable?
sh-4.1$
Please let me know how can I resolve the above error and also how to attach to new package.
My phone is not rooted. Hope this wont affect the gdb.
This was not helpful as well Link to similar problem. As my phone is new phone and dont have any app, other than the current developing app. (Only packages which come along with the Samsung phone are present. No app is downloaded from the market. )
Thanks & Regards,
SSuman185
Please go through the link Debugging native code in android app using the android ndk gdb
Please first ensure that you are building the debuggable version of the app. The AndroidManifest.xml file should include the android:debuggable="true" tag.
You can also check it by finding the APK file in the bin directory, unpacking it (it's just a renamed ZIP file) and ensuring that lib\armeabi folder contains the gdbserver file.
If both conditions above are met, try installing the package on the device manually:
<android-sdk>\platform-tools\adb.exe install -r <your-package-file.APK>
Please carefully observe the output of adb.exe. If it displays an error, it might explain your problem.
This problem will arise if you try to debug a library project.
ndk-gdb is unable to attach to a project that is not the "main" one.
You have to put your jni code into the starting application project.
make sure you have APP_OPTIM in jni/Application.mk set to debug
According to http://developer.samsung.com/forum/thread/ndk-debugging-with-gdb/77/178834 some Samsung phones are not native debuggable without rooting because run-as is broken
See run-as Package 'a.b.c' is unknown - Galaxy S4 Jellybean or Android 4.3 for my solution
I am using vs-android for building native C++ Android applications. I would like to debug from the command line by launching gdbserver on the emulator and connecting to that GDB server. Since I'm not using the Android build scripts I don't get the gdbserver delivered by default. So I added gdbserver to the lib folder from where vs-android collects it and pushes it into the APK. The file is now found on the emulator in the lib folder of the application where my SO is also located when I deploy the application with adb install.
I now try to run gdbserver with run-as but I get the error "Cannot attach to process 924: Operation not permitted (1)".
According to this http://ian-ni-lewis.blogspot.com/2011/05/ndk-debugging-without-root-access.html the server should be able to attach to the process when gdbserver is started with run-as.
Any ideas as to what I could still be doing wrong?
adb shell
su -c setenforce 0
it will solve the problem
To figure out if the problem is with run-as or with gdbserver, try using run-as to execute 'ps' instead of gdbserver, and then see if the 'ps' process is listed as having the same userid as the application's process. If not, you have a problem with run-as. If it is the same userid as the app, then the problem is more likely with gdbserver.
Can anyone tell me how to run ndk-gdb from within emacs using gdb-mode? I'm currently running it in a shell buffer. What I'd love to have is a way to automatically sync a source file buffer with the current pc in gdb when I break or step. Anything more, like setting breaks from source, buffers that show gdb locals etc., and key shortcuts for gdb commands would be gravy.
Background: I'm developing in GNU Emacs 23.1.90.1 (i386-apple-darwin10.5.0, NS apple-appkit-1038.35) of 2010-12-15 on OSX 10.6.6 with android-mode, using android-ndk-r5b and mixed java/c/c++ code for an android target.
Android-mode and shell (running ndk-gdb) within emacs allow me to see just about everything I need, but my setup would be more convenient if I could get a source buffer to sync with the debugger, or get the equivalent of what is described in EmacsWiki here.
FYI, I'm currently using eclipse for java side debugging and development, but finding it unstable and difficult to set up for native work, despite the availability of sequoyah, and besides, eclipse is no emacs.
[Appended]
Running M-x gdb with ndk-gdb as the gdb command (see below) results in a buffer called gud with a modeline saying "(Debugger:run [initializing...])". The buffer does not accept gdb commands, nor does it accept emacs gdb commands - (M-s, M-n etc result in <>
Output:
Current directory is /Users/jpschelter/
Android NDK installation path: /Developer/android-ndk-r5b
Using specific adb command: /Developer/android-sdk-mac_x86/platform-tools/adb
...
... ...
...
(no debugging symbols found)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0xafd0e21c in nanosleep () from /Developer/Projects/ECS/DIGG/Projects/droid/obj/local/armeabi/libc.so
(gdb) Undefined command: "1-inferior-tty-set". Try "help".
(gdb) Undefined command: "2-gdb-set". Try "help".
(gdb) Undefined command: "3-gdb-set". Try "help".
(gdb) Undefined command: "4-file-list-exec-source-files". Try "help".
(gdb) Undefined command: "5-file-list-exec-source-file". Try "help".
(gdb) Undefined command: "6-gdb-show". Try "help".
(gdb) Undefined command: "7-stack-info-frame". Try "help".
(gdb) Undefined command: "8-thread-info". Try "help".
(gdb) Undefined command: "9-break-list". Try "help".
Buffers called *threads of*, *input/output of* and *breakpoints of* are also created, but are empty.
Browsing through the gdb-mi.el source of my emacs, and comparing to the gdb-debug-log output, it looks like gdb-mi is trying to send these parameters to a gdb executable, but gdb-server is not responding to the commands as expected?
Note that running M-x gud-gdb with the command-line for ndk-gdb seems to result in the equivalent of running ndk-gdb within a shell, so the issue seems to be within the configuration of gdb-mode in emacs.
I had the exact same problem when running gdb under emacs: the *gud* window was not responding to commands. However, ndk-gdb was working well in a shell. To make it work under the emacs gud UI, I had to modify the ndk-gdb script a bit.
On call to GDB (last line), do this:
$GDBCLIENT --annotate=3 -x `native_path $GDBSETUP`
The --annotate=3 option is mandatory for emacs gud interface, it cannot work without it (that's why *gud* was not responding).
But you're halfway. Now it will work, but only if you invoke ndk-gdb while in a buffer from a file at the root of the project (like AndroidManifest.xml). Since this is very unlikely most of the time because you are a C/C++ programmer and the sources you're working on are under the jni directory or deeper, you need to do a little more. The ndk-gdb script is a bit buggy and it will happily confuse you on this one (and gdb itself won't help much either).
Search the script for "PROJECT=$OPTION_PROJECT". You will be in a long if...else...fi clause which is in charge of finding the root of the project (if it has not been given with the --project option, though doing so WILL NOT resolve the issue I talk about, see below). After the fi, add this line:
cd $PROJECT
For some obscure reason, the script DOES NOT cd to the project root directory. This leads to very wrong behaviour when dealing with the gdb.setup file where the script assumes to be at project root. Adding this line will fix it.
Make sure you call ndk-gdb within emacs with the usual command:
(gdb "ndk-gdb ...")
Do not use gud-gdb (oddly, this is old emacs way of using gdb and has nothing to do with the nice UI you're searching for). Replace ... with your arguments, (concat ...) or anything you wish. I strongly recommend to use the --project option anyway. If you don't and you are in a buffer for a file which is out of the project, the script won't find the root. Worse, if you're in a file in another Android project, it will find the root of that project instead (maybe even copying gdb.setup and stuffs into it before failing the gdb session). So give that damn --project option. If you're using emacs desktop command set, do this:
(gdb (concat "ndk-gdb --project=" desktop-dirname ...))
(assuming your .emacs.desktop is at the root of the project, of course).
Now you can finally debug with gud UI, setting breakpoints at source level.
Note that I use emacs 23.3.1 (gdb-ui.el), so there is no need to have 24 for this to work.
Have you tried this?
Add android-sdk-mac_x86/platform-tools and android-ndk-r5b to PATH environment. After that, start gdb mode with ndk-gdb script.
M-x gdb
Run gdb (like this): ndk-gdb --verbose --start --project=your_NDK_project_dir