|
From: Greg P. <gp...@ap...> - 2010-09-08 20:19:11
|
On Sep 8, 2010, at 7:26 AM, Seagle, Roger Lee wrote: > Thank you for your help. My understanding of the Mac OS X ASLR feature is that the mappings are stored in a file: > > /var/db/dyld/dyld_shared_cache_i386.map > /var/db/dyld/dyld_shared_cache_x86_64.map > > for 32 and 64 bit libraries, respectfully. An entry in the file is: > > /System/Library/Frameworks/SyncServices.framework/Versions/A/SyncServices > __TEXT 0x90003000 -> 0x90146000 > __DATA 0xA0000000 -> 0xA000B000 > __OBJC 0xA000B000 -> 0xA0020000 > __LINKEDIT 0x99B02000 -> 0x9B7C7000 > > My interpretation, which could be false, of this file is that the __TEXT addresses give the location of the shared library when it is loaded into memory. These randomizations are only updated when patches are applied via Mac OS X Software Update or by, I think, manually running the update_dyld_shared_cache command. I have verified that separate runs of the same program using gdb load libraries and functions in the same locations (My reliance on gdb here could be a problem.) Ignore the dyld shared cache maps. valgrind disables the dyld shared cache in the inferior, so the load addresses used by valgrind will not match the load addresses cooked into the dyld shared cache. > I totally agree with your point on Linux ASLR and shared libraries being relocatable. It does appear that valgrind is moving the shared libraries to different locations than specified in the shared_cache files. I did two separate testing runs and had the same function appear in the same location when connecting gdb to the valgrind instances. > > This brings up the key question I'm trying to answer. Is there a way to map the valgrind IMark instruction addresses back to a disassembly of a shared library? Once again thank you for helping out. 1. Find the actual load address used for the library's __TEXT segment (assuming you want to look at code and not data). `vmmap` on the valgrind process should tell you this. 2. Compute the offset from __TEXT to your pointer. 3. Run `gdb -arch <arch> /path/to/library`. Be sure to specify the correct architecture for universal libraries. 4. Find the load address that gdb used for the library's __TEXT segment. `info sharedlibrary` should tell you this. 5. Disassemble at #4 + #2. -- Greg Parker gp...@ap... Runtime Wrangler |