This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Questions about another usage of GCOV


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]