On 6/18/19 3:31 PM, david.tay...@dell.com wrote: > Dell Customer Communication - Confidential > >> From: Martin Liška <mli...@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... >
