|
From: Seagle, R. L. <rs...@ut...> - 2010-09-08 14:26:46
|
Hi Tom,
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.)
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.
Roger
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Wed 9/8/2010 9:46 AM
To: Seagle, Roger Lee
Cc: val...@li...
Subject: Re: Valgrind Instruction Tracing Tool - Mac OS X 10.6
On 08/09/10 14:25, Seagle, Roger Lee wrote:
> The addresses in many of these functions do not even correspond to the
> correct memory map of the program, when doing a vmmap -pid #, where # is
> the pid of the running program. Is this just a bug in my code? Or
> problems with handling Mac OS X ASLR? Or even a problem with Valgrind's
> support of Mac OS X Snow Leopard? Any help with this issue is greatly
> appreciated.
You are making a (probably false) assumption that code in a shared
library will be loaded at the same address every time a program is run.
That certainly isn't true on linux, at least if various address space
randomisation options are turned on in the kernel. It or may not be true
on your platform.
It is even less likely to be true between valgrind and non-valgrind runs
of the program however as valgrind reserves some address space for
itself and will force shared libraries to load outside that area of
address space if possible, overriding the default address they were
linked for.
Basically, shared libraries are relocatable and you shouldn't assume
they will always be in the same place in memory.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|