How to determine where the shared library is loaded in the process address space?
I am trying to debug a shared library that I have source code and symbol debugging for using gdb.
I have no debug 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 out to simulate a situation where I have no code).
The process prints the address for the target function foo. I am trying to debug to check that gdb knows the correct location for symbols from a shared library. foo my shared library exists. My printing method is to add the following line to the binary that my shared library uses:
printf("%p\n", foo)
... and to add complexity, this is the Android system from which I am debugging remotely.
The script I am trying to do is as 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 the 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 is the moved .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 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 should 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 to set 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 of my binary, which was 0xb6ea4217 (printed on screen).
It looks like I haven't provided the correct memory location for the shared library, but I don't know why.
Any help is appreciated!
source to share
Okay, so after scratching my head on this one time and shutting down for a while, I finally discovered what went wrong.
The solution came from a different angle, I recently had to debug some code for which I had partial sources, so I did hybrid debugging of the source / assembly and noticed that when debugging the source, everything starts to get garbled - I cannot use the following instruction as it works - but when I debug the instructions everything works great!
Then I 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 won't debug properly (debug build works, original debug doesn't work).
Then I noticed that argc was OPTIMIZED OUT!
So ... what actually happened here is a compiler optimization that prevents debugging of the source code as there is no 1: 1 relationship 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 help!
source to share