|
From: Benoit P. <ben...@en...> - 2005-04-19 13:45:22
|
Hi, I'm developping a coverage tool for valgrind. I've got almost all=20 data I need but I can't find in which directory is a source file for a given symbol.=20 Does valgrind read this in formation ?=20 If yes, in which structure can I find it ? Thank you, Benoit |
|
From: Benoit P. <ben...@en...> - 2005-04-16 17:50:08
|
Hi, I'm trying to develop a source coverage tool vor valgrind. I've got almost = all=20 data I need but I can't find in which directory is a source file for a given symbol.=20 Does valgrind read this in formation ?=20 If yes, in which structure can I find it ? Cheers, Benoit |
|
From: Nicholas N. <nj...@cs...> - 2005-04-19 23:52:14
|
On Tue, 19 Apr 2005, Benoit Peccatte wrote: > I'm developping a coverage tool for valgrind. How does it work? Is the output gcov-compatible? Does it give percentage coverage per file? I'm curious. > 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. N |
|
From: Benoit P. <ben...@en...> - 2005-04-22 09:22:27
|
Le mer 20/04/2005 =E0 01:52, Nicholas Nethercote a =E9crit : > On Tue, 19 Apr 2005, Benoit Peccatte wrote: >=20 > > I'm developping a coverage tool for valgrind. >=20 > How does it work? Is the output gcov-compatible? Does it give percentag= e=20 > coverage per file? I'm curious. The output is currently a file containing information about how many times each function/source line has been called or not called. I made a perl script that parses it and produces a summary withpercentage per function and file. Now I'd like to add a source file viewer which could navigate through source files and display those informations. > > I've got almost all data I need but I can't find in which directory is = a=20 > > source file for a given symbol. Does valgrind read this in formation ? >=20 > I don't think so. Too bad, should I use a DWARF reader library ? |
|
From: Josef W. <Jos...@gm...> - 2005-04-22 12:07:01
|
On Friday 22 April 2005 11:21, Benoit Peccatte wrote: > Le mer 20/04/2005 =C3=A0 01:52, Nicholas Nethercote a =C3=A9crit : > > On Tue, 19 Apr 2005, Benoit Peccatte wrote: > > > I'm developping a coverage tool for valgrind. > > > > How does it work? Is the output gcov-compatible? Does it give > > percentage coverage per file? I'm curious. > > The output is currently a file containing information about how many > times each function/source line has been called or not called. How do you detect source lines with code never executed? > I made a perl script that parses it and produces a summary > withpercentage per function and file. > Now I'd like to add a source file viewer which could navigate through > source files and display those informations. How about using cachegrind's format as output? Then you can use=20 cg_annotate/KCachegrind as Viewer/Browser. In this format, you can specify arbitrary events (names are specified in a= =20 header), and 64bit integer values for these events, related to source code= =20 lines (callgrind extends this to allow for relation to instructions). See cachegrind docu and/or=20 http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindCalltreeForm= at If that is not enough, the format could be extended (in an compatible way). 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= =20 for the overview: You get the sorted list of function where a lot of lines= =20 are never executed. It would be good here to define derived events like "2) divided by 1)", to = get=20 the percentage values calculated. This is interesting for cachegrind itself= =20 (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 operato= r=20 "+". I would add "/" for you ;-) And callgrind even extends cachegrind's format to allow to specify derived= =20 metric 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 wi= th=20 the directory name while loading the debug info... But is this needed? With cg_annotate / KCachegrind you can specify the directories where to loo= k=20 for source. Of course there is a problem if a program has source files with= =20 the same name. Josef |
|
From: Benoit P. <ben...@en...> - 2005-04-22 14:59:15
|
Le ven 22/04/2005 =E0 14:04, Josef Weidendorfer a =E9crit : > On Friday 22 April 2005 11:21, Benoit Peccatte wrote: > > The output is currently a file containing information about how many > > times each function/source line has been called or not called. >=20 > 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. > > I made a perl script that parses it and produces a summary > > withpercentage per function and file. > > Now I'd like to add a source file viewer which could navigate through > > source files and display those informations. >=20 > How about using cachegrind's format as output? Then you can use=20 > cg_annotate/KCachegrind as Viewer/Browser. 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.=20 > 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 importa= nt=20 > for the overview: You get the sorted list of function where a lot of line= s=20 > are never executed. We don't know when a line don't have debug info, we even don't know that it= exist. 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. > It would be good here to define derived events like "2) divided by 1)", t= o get=20 > the percentage values calculated. This is interesting for cachegrind itse= lf=20 > (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 opera= tor=20 > "+". I would add "/" for you ;-) > And callgrind even extends cachegrind's format to allow to specify derive= d=20 > metric formulas. I don't really understand here. Should I calculate the percentage withing t= he tool ? How can I specify or get values for summary such as percentage of executed = code=20 by function, by file or by soname ? > > > > 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 format= ion > > > > ? > > > > > > I don't think so. > > > > Too bad, should I use a DWARF reader library ? >=20 > A long time ago I had a local patch for prefixing every source file name = with=20 > the directory name while loading the debug info... This is exactly whan I need, I would be glad if you could find it. > But is this needed? > With cg_annotate / KCachegrind you can specify the directories where to l= ook=20 > for source. Of course there is a problem if a program has source files wi= th=20 > 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. |
|
From: Nicholas N. <nj...@cs...> - 2005-04-22 18:31:55
|
On Fri, 22 Apr 2005, 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. That's interesting, I've been working on a coverage tool that works in the same way. N |
|
From: Benoit P. <ben...@en...> - 2005-05-02 15:39:25
|
Le ven 22/04/2005 =E0 18:52, Josef Weidendorfer a =E9crit : > > > > > > I've got almost all data I need but I can't find in which direc= tory > > > > > > is a source file for a given symbol. Does valgrind read this in > > > > > > formation ? >=20 > 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=20 > for vg_symtab2.c. I've found it, but the files found in STABS are not the ones I want. I need the real source path found in dwarf informations. =46rom vg_dwarf.c I an read : /* We ignore the directory table, since gcc gives the entire path as part of the filename */ But : - I don't get the entire path of source files - This directory table doesn't contain the path I need. I can find the information I need using dwarfdump -l but I don't know=20 where to find this section and how to include it in valgrind's data structure. Does anybody have a pointer on this ? |
|
From: Benoit P. <ben...@en...> - 2005-05-04 13:42:07
|
Le lun 02/05/2005 =E0 20:49, Nicholas Nethercote a =E9crit : > On Mon, 2 May 2005, Benoit Peccatte wrote: >=20 > > > > I can find the information I need using dwarfdump -l but I don't know > > where to find this section and how to include it in valgrind's data > > structure. > > > > Does anybody have a pointer on this ? >=20 > I believe Eric Estievenart may have posted a patch for this for his Valgu= i=20 > tool on the valgrind-developers list at some point last year. I haven't=20 > looked for it myself, but if you find it I'd like to know. It is distributed with valgui in the patch directory. However, the last one is for valgrind 2.2 I haven't tried to adapt it to 2.4 yet. |
|
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 |
|
From: Benoit P. <ben...@en...> - 2005-04-25 15:09:06
|
Le ven 22/04/2005 =E0 18:52, Josef Weidendorfer a =E9crit : > 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. >=20 > Ah, good. I didn't know you can iterate over debug info in a Valgrind too= l. Well, I didn't use directly valgrind functions. I copied needed structures from vg_symtab.h into the tool's header. I know that's not perfectly clean, but it works for now.=20 > > How can I specify or get values for summary such as percentage=20 > > of executed code by function, by file or by soname ? >=20 > 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 =3D Executed / DebugInfo > and will calculate everything itself. But note that currently there is no= =20 > support for parsing "/" in formulas. Ok, I understand now. Yes I would need the '/' then, but I can't see where the '+' is parsed.=20 As the format is extensible, I'd like to keep a new information associated with each file name : the soname where it has been found. Can I add a so=3D... before fl=3D... ? > 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=20 > for vg_symtab2.c. Thanks. > > 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. >=20 > With KCachegrind, you only have to specify the base of the source tree, i= t=20 > will recurse into subdirs automatically. I thought the same is true for=20 > cg_annotate, but if not, this should be easy to add. The project I'm working on have several files with the same name. This is not sufficient. |
|
From: Josef W. <Jos...@gm...> - 2005-04-25 16:00:07
|
On Monday 25 April 2005 17:08, Benoit Peccatte wrote: > Le ven 22/04/2005 =C3=A0 18:52, Josef Weidendorfer a =C3=A9crit : > > Ah, good. I didn't know you can iterate over debug info in a Valgrind > > tool. > > Well, I didn't use directly valgrind functions. I copied needed > structures from vg_symtab.h into the tool's header. I know that's not > perfectly clean, but it works for now. It would be good to have some iterator functions for debug info available f= or=20 tools. Structs are bad wrt. interface stability. > > header like > > event: Coverage =3D Executed / DebugInfo > > and will calculate everything itself. But note that currently there is = no > > support for parsing "/" in formulas. > > Ok, I understand now. Yes I would need the '/' then, but I can't see > where the '+' is parsed. =46ormulas for derived events are only possible in KCachegrind for the mome= nt.=20 Interpreting formulas should be not to difficult to add in a PERL script li= ke=20 cg_annotate (via "eval"). I'll try. > As the format is extensible, I'd like to keep a new information > associated with each file name : the soname where it has been found. > Can I add a so=3D... before fl=3D... ? Do you mean the file name of a shared library, or the soname defined in the= =20 shared library? The file name of the shared lib is stored in callgrind file= s=20 via "ob=3D" (meaning: ELF object). It would be nice if we could use the sam= e. BTW, what are you using this for? In callgrind, I can relate metrics to=20 instruction addresses, and KCachegrind has assembler annotation. It needs t= he=20 libraries file name to call "objdump" to get disassembled code. It seems quite natural for me to also do code coverage on this level. Then = you=20 would also get information for a source line like: "only 20% of instruction= s=20 attributed to this source line are executed". Josef |
|
From: Benoit P. <ben...@en...> - 2005-04-25 16:58:11
|
Le lun 25/04/2005 =E0 18:02, Josef Weidendorfer a =E9crit : > It would be good to have some iterator functions for debug info available= for=20 > tools. Structs are bad wrt. interface stability. Yes.=20 If I want to provide a patch for this (and maybe for other tools) how should I proceed ? > > As the format is extensible, I'd like to keep a new information > > associated with each file name : the soname where it has been found. > > Can I add a so=3D... before fl=3D... ? >=20 > Do you mean the file name of a shared library, or the soname defined in t= he=20 > shared library? The file name of the shared lib is stored in callgrind fi= les=20 > via "ob=3D" (meaning: ELF object). It would be nice if we could use the s= ame. Let's go for ob=3D > BTW, what are you using this for? I'm using this to group source files in the summary. Sources can be grouped by library, or by directory. That's why I don't really mind if it's the filename or the soname, though the filename may be more explicit to developers. > It seems quite natural for me to also do code coverage on this level. The= n you=20 > would also get information for a source line like: "only 20% of instructi= ons=20 > attributed to this source line are executed". It does coverage at debug level, this means that if there are multiple instructions associated with a line you can have 20% of a line executed. But this is not assembler level, the compiler doesn't associate each opcode with a line. For example a for loop line can be executed from 2 places (so either 0%, 50% or 100%). I don't think getting deeper is usefull. Usually you don't want to get assembler coverage for extern libraries. If you are coding in assembler, doesn't your compiler add this information already ? Benoit |
|
From: Nicholas N. <nj...@cs...> - 2005-05-02 18:49:43
|
On Mon, 2 May 2005, Benoit Peccatte wrote: >>>>>>> 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 can find the information I need using dwarfdump -l but I don't know > where to find this section and how to include it in valgrind's data > structure. > > Does anybody have a pointer on this ? I believe Eric Estievenart may have posted a patch for this for his Valgui tool on the valgrind-developers list at some point last year. I haven't looked for it myself, but if you find it I'd like to know. N |
|
From: Nicholas N. <nj...@cs...> - 2005-05-04 14:57:47
|
On Wed, 4 May 2005, Benoit Peccatte wrote: >> I believe Eric Estievenart may have posted a patch for this for his Valgui >> tool on the valgrind-developers list at some point last year. I haven't >> looked for it myself, but if you find it I'd like to know. > > It is distributed with valgui in the patch directory. However, the last > one is for valgrind 2.2 > > I haven't tried to adapt it to 2.4 yet. I don't think the debug info reader has changed much between 2.2 and 2.4 so hopefully it won't be hard to integrate. N |
|
From: Benoit P. <ben...@en...> - 2005-05-08 21:28:19
Attachments:
filenames.patch
|
On Wed, 4 May 2005 09:57:37 -0500 (CDT) Nicholas Nethercote <nj...@cs...> wrote: > On Wed, 4 May 2005, Benoit Peccatte wrote: > > >> I believe Eric Estievenart may have posted a patch for this for his Valgui > >> tool on the valgrind-developers list at some point last year. I haven't > >> looked for it myself, but if you find it I'd like to know. I have taken this patch and modified it a bit so that it be more generic. Which means it now uses an option named --long-filenames to enable the display of full path for source files. This patch is made for valgrind 3.0 from subversion. This can be usefull not only for cover but for cachegrind too. So I'm wondering if such a patch could be included in valgrind. |
|
From: Josef W. <Jos...@gm...> - 2005-05-09 10:03:12
|
On Sunday 08 May 2005 23:27, Benoit Peccatte wrote: > I have taken this patch and modified it a bit so that it be more generic. > Which means it now uses an option named --long-filenames to enable the > display of full path for source files. > > This patch is made for valgrind 3.0 from subversion. > > This can be usefull not only for cover but for cachegrind too. > So I'm wondering if such a patch could be included in valgrind. Cool. Of course, it is interesting for callgrind likewise. But why a global command line option for all tools? This looks like a temporary hack to me. I think the tool should have control over whether it gets a file name with or without full directory. This really should be part of a debug info request API, part of the tool API. Make UnitInfo as opaque data structure visible to the tool API (like SegInfo), and add a getDirectory(UnitInfo*). An iterator for debug line info would be getFirst/NextLine(UnitInfo*, int* line, Addr* addr) with (line,addr) as output. The next step would be to make your tool independent from the internal VG structures by using this debug line iterator. This way, the debug info request API is used and can be improved for the needed szenarios of tools (Perhaps the suggested API functions are totally bogus for your needs). Josef |
|
From: Benoit P. <ben...@en...> - 2005-05-09 12:46:55
|
Le lun 09/05/2005 =E0 11:59, Josef Weidendorfer a =E9crit : > On Sunday 08 May 2005 23:27, Benoit Peccatte wrote: > > I have taken this patch and modified it a bit so that it be more generi= c. > > Which means it now uses an option named --long-filenames to enable the > > display of full path for source files. > > > > This patch is made for valgrind 3.0 from subversion. > > > > This can be usefull not only for cover but for cachegrind too. > > So I'm wondering if such a patch could be included in valgrind. >=20 > Cool. Of course, it is interesting for callgrind likewise. >=20 > But why a global command line option for all tools? This looks like a=20 > temporary hack to me. >=20 > I think the tool should have control over whether it gets a file name wit= h or=20 > without full directory. This really should be part of a debug info reques= t=20 > API, part of the tool API. It's a matter of taste, but why should a tool control for the user how filenames are handled ? > Make UnitInfo as opaque data structure visible to the tool API (like SegI= nfo),=20 > and add a getDirectory(UnitInfo*). An iterator for debug line info would = be > getFirst/NextLine(UnitInfo*, int* line, Addr* addr) with (line,addr) as=20 > output. There are many UnitInfo, if you want to store ther you have to add a table of UnitInfo and add a reference to them in the RiLoc structure. > The next step would be to make your tool independent from the internal VG= =20 > structures by using this debug line iterator. This way, the debug info=20 > request API is used and can be improved for the needed szenarios of tools > (Perhaps the suggested API functions are totally bogus for your needs). I intend to do such a thing soon since I've just adapted my tool to valgrind3.0 |
|
From: Josef W. <Jos...@gm...> - 2005-05-09 21:26:05
|
On Monday 09 May 2005 14:46, Benoit Peccatte wrote: > > I think the tool should have control over whether it gets a file name > > with or without full directory. This really should be part of a debug > > info request API, part of the tool API. > > It's a matter of taste, but why should a tool control for the user how > filenames are handled ? Because the use of a long or an abbreviated file name without path depends on the context which only the tool knows about? E.g. for the output, it is clear that cachegrind/callgrind/cover always wants the full path, so that postprocessing tools can do annotation. If the postprocessing tool wants to show human readable output, it can strip the path itself. If the tool itself wants to produce human readable output, it could ask for the abbreviated version (API), or strip the path itself, too. In this case, I would simply remove the option, and even for the API, it is only convenience, but not really needed. I called it a "hack" because it looked like changing the semantic of an API from the outside ( e.g. VG_(get_filename_linenum)() ). > > Make UnitInfo as opaque data structure visible to the tool API (like > > SegInfo), and add a getDirectory(UnitInfo*). An iterator for debug line > > info would be getFirst/NextLine(UnitInfo*, int* line, Addr* addr) with > > (line,addr) as output. > > There are many UnitInfo, if you want to store ther you have to add a > table of UnitInfo and add a reference to them in the RiLoc structure. You need to have a way to iterate over the source files of a library, don't you? Josef > I intend to do such a thing soon since I've just adapted my tool to > valgrind3.0 |