|
From: Bryan M. <om...@br...> - 2006-08-06 23:33:09
|
Josef, you sir, are a star. :D For now, I have made the function name the same as the file reference number. There is some other tidying up to do but its worth a Beta-02, just to be able to see the output with kcachegrind. One thing of note - I set the context in kcachegrind to be 50 so that in effect, the whole of the file is displayed. The display goes past the end of the file. I shall download the latest source (really not sure what version I am running) and see if I can put a patch together for you to consider. There is also the issue of showing source files that don't get hit at all - maybe there is some scan that could be run from a menu option for that? I don't know. I will look at this as well. The "ignores some files" thing is because I can only have 499 items in a list box. This is going to be a major headache at work where the file count is well above 1000 (and probably at least 2000). I shall have another read through the source for the debug information parsing. I don't want to do anything whilst the program is running but appreciate that if an object unloads, the debug potentially goes with it so I shall have to think about that one. There is a good argument for having a set of bit flags per source file to show executable lines in order to keep the data compact. I really do need to have a look and think on that one though. Thanks for the guidance. I won't announce Beta-02 (but it is on my website now if you (or anyone else) wants to play). I shall cleanup a few more things first then release a Beta-03. Thanks again for your input - it has made my weekend. Bryan "Brain Murders" Meredith Josef Weidendorfer wrote: > 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 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |