Hi All. I have some questions regarding GCOV, which is part of GCC. I hope this is the right place (if not, suggestions are welcome).
Please add me (marc dot alff at comcast dot net) in your replies, as I am not subscribed to this list. Let me start with some background : A project "XYZ" consist of : - a programming language "XYZ", - a server, which interprets the XYZ code at runtime. This language is procedural, but can not be compiled into binary code in a traditional sense like C, C++, Java, Fortran etc, so it's not a language that is likely to be supported by GCC. Yet, the language defines concepts like : - procedures, functions, - flow control statements (if, while, switch/case, etc). The goal is to instrument the code in the interpretor in the XYZ server, to basically compute code coverage on paths executed at runtime, the have same functionality for "XYZ" that GCOV provides for GCC. Looking at how GCOV works, I found that : - GCOV only cares that code is located on a file+line, - the programming language is not important, only the graph representing the code is. So, what I have in mind is the following : When some code is loaded in the XYZ server, generate a .gcno file Loading function foo.xyz (typically done once) : foo.xyz ---- (server) ----> foo.gcno When code is executed, generate a .gcda file Executing function foo.xyz : request that invokes foo() ---- (server) ----> foo.gcda After the code has been executed, coverage can be collected : foo.xyz + foo.gcno + foo.gcda ---- (GCOV) ----> foo.xyz.gcov All this raises the following questions, and I appreciate your comments ... 1) File formats So far, the .gcno and .gcda file formats were "private" to the implementation of GCC, and subject to change at any time. Now, a third party (from the GCC point of view) is generating these files ... Do you welcome such a dependency ? The file formats themselves seem to be very stables (in my understanding), so this interface is well defined. There is no need to preserve data forever since coverage analysis is typically done in a build/test/fix bugs cycle, so there is no expectations that a given format will be supported by every future releases of GCC, so this now external dependency does not add constraints to the GCC code base (in my opinion). The question is if you feel this usage of GCOV is fair, or if it's unwelcome. The underlying question is whether using GCOV for languages not supported by GCC can be done (and how ?). 2) Licensing For technical reasons, I can not use the gcov library itself, and plan to implement code to read/write the files the GCOV program needs. Is the file format (for *.gcno and *.gcda) itself covered by the GPL ? Can a third party implement, with original code not based on GPL'ed work, a library that knows how to read/write *.gcno and *.gcda files ? How much does "reading comments that specify a file format in gcov-io.h and implementing from scratch some code" constitute "a derived work" of GNU GPL code ? The new work is based on an interface specification, not on an implementation ... ... assuming the file formats are considered an interface. Is the file format documented elsewhere ? XYZ is a well known open source project I would like to contribute to, to implement code coverage in XYZ, and I am evaluating if GCOV can be leveraged or not, or under what conditions. Early prototyping shows that from a pure technical point of view, it works :) Licensing in this case is a very tricky question, because the code base of XYZ itself happen to be covered by a dual license : either GNU GPL, or commercial. When XYZ is used under the terms of the GNU GPL license, it's simple. When XYZ is used under the terms of the commercial license : - XYZ contains in it's code base original code (not GCC's) to read/write *.gcno and *.gcda - XYZ write files during it's execution - GCOV, used as a stand alone program, later consumes these files. So, XYZ and GCOV are independent programs, and are not linked together. Is that usage of GCOV a valid one ? Thanks for your time and comments, Marc Alff.