From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49426 invoked by alias); 4 Nov 2019 13:45:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 49401 invoked by uid 89); 4 Nov 2019 13:45:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=commercial, console, forcing, H*f:sk:4005ef6 X-HELO: mail-ed1-f47.google.com Received: from mail-ed1-f47.google.com (HELO mail-ed1-f47.google.com) (209.85.208.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Nov 2019 13:45:32 +0000 Received: by mail-ed1-f47.google.com with SMTP id l25so13167635edt.6 for ; Mon, 04 Nov 2019 05:45:31 -0800 (PST) Return-Path: Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id u24sm955114edt.84.2019.11.04.05.45.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2019 05:45:28 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id x4so5584459wmi.3 for ; Mon, 04 Nov 2019 05:45:28 -0800 (PST) MIME-Version: 1.0 References: <25767.1572632020@usendtaylorx2l> <194f90a5-6a02-b8ee-d454-fe1338a2f542@suse.cz> <4005ef638f4a46ce9a99e5eee3531c3a@x13pwdurdag1005.AMER.DELL.COM> In-Reply-To: <4005ef638f4a46ce9a99e5eee3531c3a@x13pwdurdag1005.AMER.DELL.COM> Reply-To: joel@rtems.org From: Joel Sherrill Date: Mon, 04 Nov 2019 13:45:00 -0000 Message-ID: Subject: Re: GCC's instrumentation and the target environment To: David.Taylor@dell.com Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00024.txt.bz2 On Mon, Nov 4, 2019 at 7:06 AM wrote: > > From: Martin Li=C5=A1ka > > 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=3D/mnt/mynfs/...)? > > I/O encompasses more than just reading and writing a file in a file syste= m. > 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. > And I generally agree with that statement but I am also on a project evaluating the use of a commercial tool which does coverage and includes MCDC analysis. It has a very flexible plugin for this specific purpose. You can dump in any format you can decode to any output destination. They have many standard implementations and plenty of examples you can tailor. It wouldn't be terribly difficult to multiplex the console and filter it. I would suggest consideration for dumping into a buffer and having an external agent (e.g. debugger, JTAG based program, etc) retrieve it. RTEMS programs generally don't exit and often have no networking. You have to have flexibility. No one is forcing a singular output media -- just flexibility. I'd love to see decision and MCDC coverage support . --joel > > > Martin > > David > >