|
From: Josef W. <Jos...@gm...> - 2006-08-06 20:31:51
|
On Sunday 06 August 2006 15:08, Bryan Meredith wrote: > > fn=Unknown > > I changed Covergrind around to output this format (yes, it was simple) > then passed it into kcachegrind. I was kind of expecting individual > source files with the event marked as 1 next to all the lines that were > hit but that didn't happen - I got a single concatenated file that had > all the source regions in it and no way that I could find to show > individual files or indeed which line belonged to which source file. That one is easy. KCachegrind presents profile information at function granularity. It was my error to suggest to name everything to be in function "Unknown". Best would be to provide the function name, but even providing the file name also as function name at least shows the data at file name granularity. > I > also could not stop it from ignoring some of the files. No idea why. Can you send me an output showing this problem? Ah... it could be that KCachegrind only looks at the base name of a file and not the full path. So if you have 2 source files with same name in different directories, this could be a problem. I made this restriction because often, valgrind's debug output is not able to provide full source paths, depending on debug format and compiler. > > Hmmm... Then your GUI has to read debug info yourself. > > This could indeed be the best way forward as source parsing can be > fraught (although I was only planning on C/C++ support - the source > would be available for others to extend if they wish). Again, because of > the much less restricted environment compared to executing within > Valgrind, this could well be a simpler task to accomplish. The output > from "readelf -wl" doesn't seem to be too bad Yes. Valgrind already has this parser for debug line info, both for DWARF and STABS format. It should be possible to ask for debug info at all text addresses of an ELF object the first time you see it inside Valgrind. You would need another event name for the output, e.g. "line with code". You already can specify derived event types in Callgrinds format (which should be calculated automatically be KCachegrind). E.g. events: lineTouched lineWithCode event: coverage = lineTouched / lineWithCode event: notTouched = lineWithCode - lineTouched ... In principle, this works because KCachegrind adds up the counts for e.g. a function; lets say: 20 lines touched with 30 lines with instructions, then you get a coverage of 0,67 attributed to this function. However, one problem exists: KCachegrind currently does _not_ understand derived events with "/" in the formula (or "-" for that matter). But this should be easy to support. And this is really also interesting to get e.g. "L2 hit ratio". Josef |