GCC's instrumentation and the target environment

[David Taylor <dtaylor@emc.com>]

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?