|
From: Josef W. <Jos...@gm...> - 2005-04-24 18:02:02
|
On Friday 22 April 2005 16:59, Benoit Peccatte wrote: > > How do you detect source lines with code never executed? > > Valgrind reads a part of the dwarf informations (which are available > when you compile with -g option). Debug informations contain a list of > locations where code can be found. I read all of them for each segment > and thus know what could be run. Ah, good. I didn't know you can iterate over debug info in a Valgrind tool. > That's a good idea, I'm reading the documentation. > > But I think I may make a simple interface to be able to do it without > kcachegrind. That will work automatically, because KCachegrind will be able to read the data without problems ;-) > > I would chose the following events related to a source line > > 1) "Line has debug info" (i.e. relevant code for coverage): Yes 1, No 0 > > 2) "Line was NOT executed" Yes: 1, No: 0 > > As cg_annotate sorts according highest values, the "NOT" in 2) is > > important for the overview: You get the sorted list of function where a > > lot of lines are never executed. > > We don't know when a line don't have debug info, we even don't know that it > exist. Yes of course. The programmer has to compile with -g. The thing is, that you want to know which lines have debug info. And you know about this. So I was a bit misleading: Every source line listed in the output of the tool would have a "1" for 1). I think you need this to calculate percentage, and still use the cachegrind format: It makes no sense to write percentage values into the output, because cg_annotate/KCachegrind will sum up events of lines to get the event count of a function, and summing makes no sense with percentage values. To be able to use the cachegrind format, cg_annotate will have to calculate the ratio. > What about an event like this : > events: Executed ExecCount > > Executed is 0 or 1 whereas ExecCount give the number of time each line was > executed. How do you get the percentage of executed lines in a function from this? Not that cg_annotate will sum up this itself from the events of the lines in the function, you can not specify this seperately. With my suggestion 1), this would give the number of lines with debug info in a function. > > It would be good here to define derived events like "2) divided by 1)", > > to get the percentage values calculated. This is interesting for > > cachegrind itself (e.g. cache hit ratio). I am sure a patch for > > cg_annotate is welcome. In KCachegrind, derived metrics are already > > possible, but only with operator "+". I would add "/" for you ;-) > > And callgrind even extends cachegrind's format to allow to specify > > derived metric formulas. > > I don't really understand here. Should I calculate the percentage withing > the tool ? My suggestion is to calculate the percentage in cg_annotate. > How can I specify or get values for summary such as percentage > of executed code by function, by file or by soname ? As said above, cg_annotate sums up this itself. The same with KCachegrind. The formula could be specified on the command line, or given in the data file. KCachegrind supports this by adding a line in the header like event: Coverage = Executed / DebugInfo and will calculate everything itself. But note that currently there is no support for parsing "/" in formulas. > > > > > I've got almost all data I need but I can't find in which directory > > > > > is a source file for a given symbol. Does valgrind read this in > > > > > formation ? > > > > > > > > I don't think so. > > > > > > Too bad, should I use a DWARF reader library ? > > > > A long time ago I had a local patch for prefixing every source file name > > with the directory name while loading the debug info... > > This is exactly whan I need, I would be glad if you could find it. I just looked, and I think it was for STABS. See http://kcachegrind.sourceforge.net/patch-0.2b-valgrind-1.0.4.gz, the part for vg_symtab2.c. > > > But is this needed? > > With cg_annotate / KCachegrind you can specify the directories where to > > look for source. Of course there is a problem if a program has source > > files with the same name. > > Yes it is, I work on a big project with many sub directories. I don't > want the user to find himself where is each source file, especially if > the software can do it automaticly. With KCachegrind, you only have to specify the base of the source tree, it will recurse into subdirs automatically. I thought the same is true for cg_annotate, but if not, this should be easy to add. Josef |