|
From: Seagle, R. L. <rs...@ut...> - 2010-09-09 14:03:01
|
Greg, Thank you for pointing out the disabling of the shared cache. I was unaware that this option was possible (I should have read the man page more thoroughly). If I'm reading the code correctly, it is being disabled in coregrind/m_initimg/initimg-darwin.c by setting the environment variable DYLD_SHARED_REGION=avoid ? I am having a problem with vmmap, where if I run it on the valgrind process it will actually crash: 2010-09-09 09:35:06.006 vmmap[37451:a07] *** Terminating app due to uncaught exception 'VMUDyld fatal error', reason: 'Attempt to get _dyld_all_image_infos failed' *** Call stack at first throw: ( 0 CoreFoundation 0x96596bba __raiseError + 410 1 libobjc.A.dylib 0x9902b509 objc_exception_throw + 56 2 Symbolication 0x92e2db64 -[VMUDyld findMachOHeadersInMemory:] + 915 3 Symbolication 0x92e2d7a4 -[VMUDyld initWithMachOHeader:memory:] + 132 4 Symbolication 0x92e2d66a +[VMUDyld dyldWithMachOHeader:memory:] + 74 5 Symbolication 0x92e420d3 -[VMUTask initWithMachTaskContainer:] + 690 6 Symbolication 0x92e41e09 +[VMUTask taskWithMachTaskContainer:] + 64 7 Symbolication 0x92e5c6f6 -[VMUVMRegionIdentifier initWithTask:] + 235 8 vmmap 0x00002c67 0x0 + 11367 9 vmmap 0x00002255 0x0 + 8789 10 ??? 0x00000003 0x0 + 3 Since vmmap is crashing, I am thinking about just setting the DYLD_PRINT_SEGMENTS and parsing the output to get the __TEXT addresses. Although, it looks like parsing the information dumped from dyld when this variable is set could be cumbersome and the output is sporadic (depends on when the library is loaded) It also look like valgrind keeps track of its memory space with coregrind/m_aspacemgr. Is it possible to get the information of mappings from here by a valgrind tool? Roger 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 |