|
From: Alexander P. <gl...@go...> - 2010-09-10 10:01:43
|
Hi Roger, You may want to take a look at https://bugs.kde.org/show_bug.cgi?id=205000 valgrind -v shows the load addresses of the shared libraries, so you can just fetch them to gdb using the add-symbol-file command, and then do the symbolization by calling "info line *<address>" Here are the scripts we use at Chromium to post-process Valgrind logs: http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/gdb_helper.py?revision=26911&view=markup -- a gdb wrapper used by the following scripts http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/memcheck_analyze.py?revision=56662&view=markup -- symbolize Memcheck's XML output http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/tsan_analyze.py?revision=57519&view=markup -- symbolize ThreadSanitizer's stderr output On Wed, Sep 8, 2010 at 5:25 PM, Seagle, Roger Lee <rs...@ut...> wrote: > 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 > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > -- Alexander Potapenko Software Engineer Google Moscow |