I wish to use GCC based instrumentation on an embedded target. And I am finding that GCC's libgcov.a is not well suited to my needs.
Ideally, all the application entry points and everthing that knows about the internals of the implementation would be in separate files from everything that does i/o or otherwise uses 'system services'. Right now GCC has libgcov-driver.c which includes both gcov-io.c and libgcov-driver-system.c. What I'd like is a stable API between the routines that 'collect' the data and the routines that do the i/o. With the i/o routines being non-static and in a separate file from the others that is not #include'd. I want them to be replaceable by the application. Depending upon circumstances I can imagine the routines doing network i/o, disk i/o, or using a serial port. I want one version of libgcov.a for all three with three different sets of i/o routines that I can build into the application. If the internals of instrumentation changes, I want to not have to change the i/o routines or anything in the application. If you think of it in disk driver terms, some of the routines in libgcov.a provide a DDI -- an interface of routines that the application call call. For applications that exit, one of the routines is called at program exit. For long running applications, there are routines in the DDI to dump and flush the accumulated information. And the i/o routines can be thought of as providing a DKI -- what the library libgcov.a expects of the environment -- for example, fopen and fwrite. There's also the inhibit_libc define. While if you don't have headers you might have a hard time including <stdio.h> or some of the other header files, if the environment has a way of doing i/o or saving the results, there is no real reason why it should not be possible to provide instrumentation. Comments?
