On 11/4/19 2:06 PM, david.tay...@dell.com wrote:
From: Martin Liška <mli...@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.
Hello.
I see your needs. I would recommend to come up with patches that will enable
such
a communication channel. I can review the patches or help you with obstacles.
Martin
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
