Re: gcc: -ftest-coverage and -auxbase

["Martin Liška" <mliska@suse.cz>]

On 6/18/19 3:31 PM, David.Taylor@dell.com wrote:
> Dell Customer Communication - Confidential
> 
>> From: Martin Liška <mliska@suse.cz>
>> Sent: Tuesday, June 18, 2019 4:56 AM
>>
>> On 6/18/19 10:40 AM, Richard Biener wrote:
>>> I don't think we want to expose -auxbase.  Iff then an alternate way
>>> to specify a coverage output file name.
>>
>> I'm not aware of it.
>>
>> @David: Can you please summarize what you want to achieve with the .gcno
>> files?
>> I can then help you.
>>
>> Martin
> 
> Thanks.
> 
> Short answer:  Some of the GNU/Linux test coverage related tools
> want them, so I want them to be available.
> 
> Longer answer:
> 
> We have purchased a third party tool for providing code test
> coverage related information.  We do not plan to abandon that
> tool as it provides more than just test coverage.  But, for test
> coverage at least, I would like an alternative.  I am exploring the
> use of GCC and related tools for this.
> 
> Our target is embedded, which presents a set of challenges.
> The set up / tear down glue code will need to be written.
> The operating system does not exit.  Data will be dumped via
> a network connection, not to a local disk.  Coverage counters
> need to be dumped and/or cleared on demand.
> 
> Additionally, since the system supports not just cold boot but
> also warm boot, initialized .data is prohibited.  So, it will be
> necessary to either put the data into a section with a different
> name and/or (ideally, both) have run-time initialization.
> 
> [My gut is that adding a command line switch to set the section
> name and finding the code that actually writes out the data to
> make use of it won't be hard.  And that run-time initialization
> will be significantly harder.]
> 
> I don't know the details of how the tools make use of the *.gcno
> files, but I assume that they either need it or give better reports
> if they have it.

.gcno files are created during compilation and contain info about a source file.
These files will be created by a cross compiler, so that's fine.

During a run of a program a .gcda file is created. It contains information about
number of execution of edges. These files are dumped during at_exit by an instrumented
application. And the content is stored to a disk (.gcda extension).

So what difficulties do you have with that please?

Martin

> 
> I want people to be able to ascertain things like
> 
> . this file has excellent coverage
> 
> . this file has horrible coverage
> 
> . this pull request affected these lines in these files, and
>   when the test suite was run these affected lines were covered,
>   but these other affected lines were not covered.
> 
> . this push will affect these lines in these files, has my testing
>   covered them?
> 
> I'm sure I left something out.  But, hopefully, you now have a
> clearer idea of what I'm trying to achieve.  Questions?  Feel
> free to ask.
> 
> I don't as yet have management buy in on this...
>