|
From: Betty W. <gre...@ho...> - 2004-09-18 04:19:37
|
Hello, Could anybody give me a hint of in the source code of Cachegrind, where would I possibly track the addresses of evey data? For example, in which file(cg_main.c?) or what data structure contains the address information of each data. I just assumed that valgrind tracks the virtual addresses of every data, is it? What I would like to do is that to look into the source code of cachegrind and be able to have a profile of what data are accessed and what their virtual(/physical?) addresses are per source code line basis. Thanks! _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |
|
From: Josef W. <Jos...@gm...> - 2004-09-20 11:48:22
|
On Saturday 18 September 2004 06:16, Betty Wang wrote: > Hello, > Could anybody give me a hint of in the source code of Cachegrind, where > would I possibly track the addresses of evey data? For example, in which > file(cg_main.c?) Yes. For every instruction executed, one of the functions=20 "log_1I_XXX_cache_access" is called, where XXX is 1Dr for a instruction=20 reading data, 1Dw for writing data, and 2D for reading and writing data. The according data address is given as argument(s). > or what data structure contains the address information of each data. > > I just assumed that valgrind tracks the virtual addresses of every data, = is > it? > What I would like to do is that to look into the source code of cachegrind > and be able to have a profile of what data are accessed and what their > virtual(/physical?) addresses are per source code line basis. I want to do this, too. There are a few things to be done: * build up a mapping structure on-the-fly holding current mapping from any= =20 data address to a source related entity. E.g. data structure, data type, C+= +=20 class, object, instance, .... for static/dynamic/automatic=3Dstack allocate= d=20 data. This needs traps for malloc/free and enter/leave of stack var scopes = +=20 interpretation of any debug infos for this purpose. AFAIK, statbs debug inf= o=20 reading for variables is already somehow in place, but for DWARF(2) it stil= l=20 has to be done. The mapping structure could be some kind of multi-level pag= e=20 table like it is done with shadow memory in memcheck. * extend the cachegrind dump format in a backward-compatible way. I would=20 suggest something like "dt=3D" (data type specification), "vr=3D" (variable= =20 name), and for every line offsets into the data type. Josef > > Thanks! > > _________________________________________________________________ > Don=92t just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2004-10-08 11:39:37
|
On Sat, 18 Sep 2004, Betty Wang wrote: > Could anybody give me a hint of in the source code of Cachegrind, where would > I possibly track the addresses of evey data? For example, in which > file(cg_main.c?) > or what data structure contains the address information of each data. > > I just assumed that valgrind tracks the virtual addresses of every data, is > it? > What I would like to do is that to look into the source code of cachegrind > and be able to have a profile of what data are accessed and what their > virtual(/physical?) addresses are per source code line basis. Have a look at the Valgrind tool Dullard, at www.cl.cam.ac.uk/~njn25/software.html. It prints out traces of memory addresses accessed as data. It would be a good starting point for any new tool, probably better than Cachegrind because it's simpler and easier to see how it works. To get the per-source-line information you'll have to do more complex stuff, though. Hope this helps. N |