RE: GCC's instrumentation and the target environment

[<David dot Taylor at dell dot com>]

> From: Martin Liška <mliska@suse.cz>
> Sent: Monday, November 4, 2019 4:20 AM
> To: taylor, david; gcc@gcc.gnu.org
> Subject: Re: GCC's instrumentation and the target environment

> On 11/1/19 7:13 PM, David Taylor wrote:

> Hello.

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/O encompasses more than just reading and writing a file in a file system.
Depending on the embedded target you might not have the ability to NFS mount.
You might not even have a file system accessible to instrumentation.

By network I/O I'm thinking sockets.  There's some code possibly run at 'boot' time or possibly run during the first __gcov_open that establishes a network connection with
a process running on another system.  There's some protocol, agreed to by the
application and remote process, for communicating the data collected and which
file it belongs to.

By serial I/O, I'm thinking of a serial port.

Hopefully that is clearer.

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

I don't think that the current implementation would make that easy.  For us there
are potentially over a thousand files being instrumented.  You need to communicate
which file the data belongs to.  Whether it is via stderr, a serial port, or a network
connection, the file name needs to be in the stream and there needs to be a way
of determining when one file ends and the next one begins.

For us, stderr and stdout, when defined, are used for communicating
status and extraordinary events.  And not well suited for transferring instrumentation
data.

> Martin

David