GCC's instrumentation and the target environment

[Martin Liška]

On 11/1/19 7:13 PM, David Taylor wrote:
> 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.

Hello.

> 
> 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.

What's difference in between i/o and disk i/o? What about using a NFS
file system into which you can save the data (via -fprofile-dir=/mnt/mynfs/...)?

I can imagine dump into stderr for example. That can be quite easily doable.

Martin

> 
> 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?
>