Develop Reference

How to tell where a shared library is loaded in process address space?

I'm trying to debug a shared library to which I have the source code and debugging symbols for using gdb.
I do not have debugging symbols or code for the process that actually uses this shared library (I compile it myself, so I can have everything, but the resulting binary is stripped, to simulate a situation where I don't have the code).
The process prints the address for target function foo I'm trying to debug, to test that gdb knows the right location for symbols from the shared library. foo exists the my shared library.
My method of printing it is adding the following line to the binary that uses my shared library:
printf("%p\n", foo)
...and to add complexity, this is an Android system I'm debugging remotely.
The scenario I'm trying follows:
On target:
root#phone:/proc/23806 # gdbserver --attach :5555 23806
Attached; pid = 23806
Listening on port 5555
Remote debugging from host 127.0.0.1
On host:
[build#build-machine shared]$ /home/build/shared/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-gdb
GNU gdb (GDB) 7.3.1-gg2
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
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-linux-gnu --target=arm-linux-android".
For bug reporting instructions, please see:
(gdb) target remote :5555
Remote debugging using :5555
0xb6f17fa0 in ?? ()
(gdb) add-symbol-file out/target/product/armv7-a-neon/symbols/system/lib/libShared.so
The address where out/target/product/armv7-a-neon/symbols/system/lib/libShared.so has been loaded is missing
Now I know what I need - the relocated .text section of this shared library in the process address space, but I have no idea how to find it.
I tried /proc/23806/smaps:
root#phone:/proc/23806 # cat maps | grep Shared
b6ea0000-b6edb000 r-xp 00000000 b3:10 3337 /system/lib/libShared.so
b6edc000-b6ede000 r--p 0003b000 b3:10 3337 /system/lib/libShared.so
b6ede000-b6edf000 rw-p 0003d000 b3:10 3337 /system/lib/libShared.so
And the .text section is located at 0x0003ff00 in the .so file:
[build#build-machine shared]$ objdump -h out/target/product/armv7-a-neon/symbols/system/lib/libShared.so | grep text
7 .text 0002835c 00003ff0 00003ff0 00003ff0 2**3
So now I'm supposed to have the address where my shared library is located:
0xb6ea0000+0x00003ff0=0xb6ea3ff0 (where the library is loaded+.text offset from the beginning)
So I did:
(gdb) add-symbol-file out/target/product/armv7-a-neon/symbols/system/lib/libShared.so 0xb6ea3ff0
add symbol table from file "out/target/product/armv7-a-neon/symbols/system/lib/libShared.so" at
.text_addr = 0xb6ea3ff0
(y or n) y
Now I tried setting a breakpoint for the foo function from my shared library:
(gdb) b F10
Breakpoint 1 at 0xb6ea41de: file frameworks/native/test/shared/src/shared, line 122.
And it doesn't match the value from my binary which was 0xb6ea4217 (printed on the screen).
It appears I did not provide the correct memory location for the shared library, but I'm clueless why.
Any help is appreciated!

Okay, so after scratching my head on this one on and off for some time now, I finally discovered what went wrong.
The solution came from a different angle, I recently had to debug some code I had partial sources for, so I did hybrid source/assembly debugging and noticed that when debugging the source, things start to skew - I can't use next instruction as it will crash - but when I debug instructions everything works great!
I then added and compiled the following short code in the AOSP tree:
int main(int argc, char** argv)
{
int first,second;
first=1;
second=2;
return first+second;
}
And, as expected, it would not debug properly (assembly debugging works, source debugging does not).
Then I noticed argc has been OPTIMIZED OUT!
So... what really happened here was a compiler optimization that prevents debugging of source code as there is no 1:1 relations between the generated instructions and the actual source. Since I left the default build flags in the hands of the AOSP build script, I got these weird debugging issues...
Thanks #EmpyloyedRussian for the assistance!

Your best bet is to run (gdb) x/10i 0xb6ea41de and (gdb) x/10i 0xb6ea4217.
I am guessing that either GDB, or your program prints the address of the PLT entry, and not the real address of foo.
P.S. Your method of calling add-symbol-file appears to be correct.

Call arguments missing when debugging with ndk-gdb. Stack trace works

I am trying to debug native code on Android using ndk-gdb, with mixed results.
When the debugger hits a breakpoint, I am able to get a nice stack trace using 'bt'.
Hhen typing 'info source', ndk-gdb tells me that the file I have hit the breakpoint in is "Compiled with DWARF 2 debugging format".
The problem arises when I enter 'info args' to get the function argument values. ndk-gdb then states that: "No symbol table info available.".
Any input to the cause of this problem would be appreciated.

It's strange that it says that about the file being compiled with DWARF 2 format, because the flags you provide there indicates it is only specifying -g, which should get GCC 4.8 to produce DWARF 4 format. Which also is consistent with the error you are seeing. Add the flag -gdwarf-2 and the NDK debugger (which is not yet at version 7.5) should be able to deal with the symbols.
I picked this up from one of the answers to this question: Debugging with gdb on a program with no optimization but still there is no symbol in the current context for local variables

Android: debug shared library

I'd like to debug android NDK application, more precisely - I want to check what arguments (r4 - r8 r1 - r4 registers) are passed to function from shared library in apk.
What I have tried:
I've run gdbserver :1234 --attach on the device
I've run arm-linux-androideabi-gdb from ndk package by Google on the PC
I've set solib-search-path and written target remote :1234
So far, so good. Now I try to set breakpoint (break <function name>) (function name from
objdump), but I get repond: Cannot access memory at address <...>. info shared says the library is loaded, Does it mean I can't set breakpoint there? Or am I doing something wrong?

The ndk-build skript does much more then you would expect.
One of the things it to copy both the gdbserver, a file called gbd.setup and the generated .so into a hidden folder called .obj/armei/
There you will have to add the libraries you would like to debug because the symbols are referencing them.
The libraries are copied from the device to your PC by some adb shell pull - commands.
I wrote an article about the topic at: http://www.professional-android-development.com/articles/android-ndk-large-c-projects
When placing the libraries into the right folder, you can set your breakpoints.
Still, for some internal reasons, they can fail.
In this case run ndk-gdb --start (the first try will also fail), enforce the application to close and rerun ndk-gdb --start (this time not forcing the application to close).

"Cannot access memory at address <...>" usually means there is a mismatch between the .so file on your PC and the .so file that is on Android. Did you recompile and reinstall?
Btw, what is the reason you're not using "ndk-gdb"? That's a script (part of the NDK) that takes care of all the gory details for you.

Can't dump the symbols of my native library : loadDataForPdb and loadDataFromExe failed

I copied the sample of Google breakpad for Android and added it to my project. I had first a problem to get the minidumps (I was triggering SIGSEGV errors but nothing was written on my SD card). I finally managed to get some minidumps (I don't really know how but that's not my main problem).
My problem is that I can't dump the symbols of my native libraries, it says the following error message :
dump_syms.exe libcppinterface.so > libcppinterface.so.sym
loadDataForPdb and loadDataFromExe failed
Open failed
Thanks for your help

The Breakpad tools are not very cross-platform friendly. You need to build dump_syms on a Linux machine in order to get a dump_syms binary that can read ELF/DWARF and produce debug symbols from your Android binaries. The Windows dump_syms.exe is only used for dumping symbols from MSVC-produced PDB files.

For a native android application that seg faults, why is there no stack trace in logcat?

Pretty self explanatory. I compiled a native c++ exe using the ndk. When I run the app, it gets a SIGSEGV, seg faults and exits. There is no stack trace or cpu context in the logcat.
Why? Any suggestions on how to fix it?

there are two tools you can use to debug your sigsev. ndk-stack and arm-linux-androideabi-addr2line located into your $NDK dir.The first help you to filter the stacktrace and addr2line translates program addresses into file names and line num. Check into your $NDK dir, for the documentation.

You're all wrong, you need to enable logging to logcat for STDIO and STDERR.
http://developer.android.com/tools/debugging/debugging-log.html#viewingStd