From: <David.Taylor@dell.com>
To: <mliska@suse.cz>, <gcc@gcc.gnu.org>
Subject: RE: GCC's instrumentation and the target environment
Date: Mon, 04 Nov 2019 13:06:00 -0000 [thread overview]
Message-ID: <4005ef638f4a46ce9a99e5eee3531c3a@x13pwdurdag1005.AMER.DELL.COM> (raw)
In-Reply-To: <194f90a5-6a02-b8ee-d454-fe1338a2f542@suse.cz>
> 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
next prev parent reply other threads:[~2019-11-04 13:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 18:18 David Taylor
2019-11-04 9:19 ` Martin Liška
2019-11-04 13:06 ` David.Taylor [this message]
2019-11-04 13:45 ` Joel Sherrill
2019-11-06 8:04 ` Martin Liška
2020-11-14 13:04 ` Sebastian Huber
2019-11-20 15:22 David Taylor
2019-11-21 12:43 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4005ef638f4a46ce9a99e5eee3531c3a@x13pwdurdag1005.AMER.DELL.COM \
--to=david.taylor@dell.com \
--cc=gcc@gcc.gnu.org \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).