Gcov: Counting lines of source code (untested files) as gcov does
Hi all! I'm currently implementing code coverage analysis in an existing build system. The code tree the system builds consists of "modules" where some code (and files) is covered by tests and some are not. To be able to present statistics "per module" I need to know how many lines of source code there is in the files that are not tested (and therefore have no .da file (I, have to, use gcc 3.3.6)). I've tried a couple of tools but to generate a fair avarage "per module" I need the tool to count lines as gcov does, which they don't. The untested files are compiled with --fprofile-arcs and -ftest-coverage so they do have .bb and .bbg files (again, I use Gcc 3.3.6) so my thinking is to extract the part of gcov.c that count source code lines and create my own tool to do this by reading the bb-file. But I've found that this is a bit "hairy" (is that an expression in english? ;)) as gcov.c depends on a bunch of other gcc files. And I suck at c to, by the way. Has anyone faced, and solved, this problem before? Perhaps someone already has created a tools that does what I need? Or does anyone has any general tips if I go forward with extracting the code from gcov.c? Thanks! Regards, Fredrik Johansson
Re: Gcov: Counting lines of source code (untested files) as gcov does
Apparently I forgot to CC this to the list last time, so here is a new attempt! Fredrik, if you can modify the source: if any line in a source file is touched, you'll get a .da file. So you could add a dummy routine to each file and call them all at startup. That will be an easier project than trying to write a new .bb/.bbg reader. In that case I guess I wouldn't need any "dummy routine" either, just include the code from a testfile that I know is beeing run, and I have one TestMain.cpp or something that loads the testsuit and such. That would work, wouldn't it? I'm at home now so I don't have the code in front of me, but an included file that isn't used get 0% coverage, right? But anyway, I would really really hate to have to alter the main code base. I'm hired over the summer to alter the build system, and if I came and told the other developers to make changes to their other components I think that would discorage them to use gcov at all, which is the opposite to what I'm hired to do :) It's not possible to "trick" gcov (or create a version of gcov that can be tricked) that there is a .da file but that no lines have been executed or something like that (the line count is done by reading the .bb anyway, right?)? Thanks! Regards, Fredrik
How gcov handles untested files, prior and after GCC 3.4
Hi! I posted a similiar thread a couple of weeks ago, but now I'm back with some more on my feet and hopefully a more clear problem description. Ok, so I have a sample application that just cout's a line of text. If I compile it with GCC 3.3.6 and run the 3.3.6 gcov on the source file I get this: Could not open data file application.da. Assuming that all execution counts are zero. 0.00% of 1 lines executed in file /usr/local/somedir/3.3.6/iostream Creating iostream.gcov. 0.00% of 4 lines executed in file application.cpp Creating application.cpp.gcov. Then I complile the exact same application with GCC 3.4.4 and I get this when using gcov on it: application.gcda:cannot open data file The 3.3.6 version assumes that the file not has been run (which is the correct behaviour in my book) whereas the 3.4.4 version just "gives up". I know that a large remake was done to gcov and it's .bb,.bbg,.da contra .gcno, gcda files when 3.4 came along, but is that the reason to change this beviour or has this been change due to some other fact? Why I ask is because I need to extract the number of lines even in untested files, and I need it to work both on 3.3.6 and on various 3.4.x versions. Thanks! Regards, Fredrik Johansson
Re: How gcov handles untested files, prior and after GCC 3.4
Ok. The reason that I need to know how many lines of source code their is in the untested files is that I want to calculate a avarage for test coverage on "modules" in my source code tree. And untested "module files" contribute to that avarage as well, of course. That I need it to work in a similiar way on different versions of Gcc is that the implementation is done in a general build system, and that I don't really know which Gcc version that is used on the host machine. The main build server is for example 3.2.3 where as most of the workstations use Gcc 4.x.x. The build system though needs to work in both environments. Regards, Fredrik On 8/4/06, Nathan Sidwell <[EMAIL PROTECTED]> wrote: Fredrik Johansson wrote: > Why I ask is because I need to extract the number of lines even in > untested files, and I need it to work both on 3.3.6 and on various > 3.4.x versions. This use case had not occurred to me. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: How gcov handles untested files, prior and after GCC 3.4
Nathan, if done properly do you think a patch (that again makes it possible to extract the number of source lines in a untested lines) would be accepted? And which way would be the most sutable: to make it the standard behaviour to assume zero counts if no .gcda file are found or to enable that feature via a flag? Regards, Fredrik On 8/4/06, Nathan Sidwell <[EMAIL PROTECTED]> wrote: Fredrik Johansson wrote: > Why I ask is because I need to extract the number of lines even in > untested files, and I need it to work both on 3.3.6 and on various > 3.4.x versions. This use case had not occurred to me. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
