|
From: Seagle, R. L. <rs...@ut...> - 2010-09-08 13:25:38
|
Hi, I am trying to develop a simplistic Valgrind tool to trace program execution of basic blocks. The tool is only meant to get the address of a basic block and catalogue it for later statistical purposes. It is really just a simpler version of callgrind. The problem I am running into is that the instruction addresses obtained from the IMark VEX instructions are not all corresponding to the location of the real instructions. The instrumentation code is very simple. To get the address from the IMark instruction I am doing: tl_assert(Ist_IMark == st->tag); origAddr=st->Ist.IMark.addr; And, I can even resolve the address to their correct function name with: VG_(get_fnname_w_offset)(origAddr, buf, BUF_LEN); Yet, when I load the program I'm emulating into gdb, the addresses of some of the functions do not match what is printed out by my Valgrind tool. For instance, the dyld library functions appear to matchup: a) Original Address: _dyld_start:0x8FE01030 b) 0x8fe01030 __dyld__dyld_start but others do not, such as the NSURL functions: a) Original Address: -[NSURL isFileReferenceURL]:0xD2B220 b) 0x96592220 -[NSURL isFileReferenceURL] In the above examples, a) is printed by the Valgrind tool and b) is printed by doing an info func in gdb. 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. Thanks, Roger Seagle |