How To Tell Where A Shared Library Is Loaded In Process Address Space?
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?"