|
From: Josef W. <Jos...@gm...> - 2006-08-07 00:32:47
|
On Monday 07 August 2006 01:32, Bryan Meredith wrote: > 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. Oops :-) > 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. I really would suggest to generate a file with the event "lineWithCode" (either within a Covergrind run, or offline), and load this into KCachegrind with the original data. Currently, you have to use "File/Add" to merge data files within KCachegrind (or use a special naming, like Callgrind is doing for parts of one profile run). Unfortunately, this merging will always default to add event counts, which is wrong for coverage: If in run 1, function foo has 20 lines touched, and in run 2, there are 15 lines touched, the merge will show 35 lines touched. It would be better for merging to specify other reductions for events types like min/max etc. With "lineWithCode", the problem to show huge context should be gone. > The "ignores some files" thing is because I can only have 499 items in a > list box. ?? Sorry, where does this limitation come from? Are you talking about Covergrind or KCachegrind? > This is going to be a major headache at work where the file > count is well above 1000 (and probably at least 2000). Hmm, shouldn't be a problem. > 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 Getting this debug information once for an ELF object should be neglectable in a Valgrind run. If you are doing multiple runs (regression tests) in a row on the same binary, you could add a command line option to do it only once. However, the current Valgrind Tool API for debug information can not simply iterate over info in a given address range, but you have to request debug info for every address, which will interally do a binary search again and again. Still, it should work reasonable fast. Josef PS: It would be perfect if KCachegrind generally would get more useful for diverse tasks. |