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!

回答1:

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.

回答2:

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!

来源：https://stackoverflow.com/questions/25844867/how-to-tell-where-a-shared-library-is-loaded-in-process-address-space

标签

android

c++

gdb

shared-libraries