Skip to content Skip to sidebar Skip to footer

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 use

Solution 1:

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:

intmain(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!

Solution 2:

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.

Post a Comment for "How To Tell Where A Shared Library Is Loaded In Process Address Space?"