Proposed Reorganization of Coverage Reporting

[Joel Sherrill]

On 11/18/2012 06:42 PM, Chris Johns wrote:
> Joel Sherrill wrote:
>> By bucket, I meant category or collection of symbols. Now we have core and "everything". I am proposing adding a report set basically by source directory.
> I am still confused. The output from the execution is parsed and reported on in a single pass and there is some sort of split of symbols based on some other data ? Where is this collection of symbols that defines these buckets ?
The key you are missing is that for a single configure/build/test run, 
you can analyse
coverage for multiple symbol subsets.
>> This would still be in addition to the -O2/-Os and posix enable/disable variations.
>>
> I would seem these and different builds, ie RFS a bucket per build type. You could visualize this as a path, ie 'rtems-O2/cpukit/libfs/rfs' and 'rtems-O2/cpukit/libfs/rfs'. These could become more complex eg 'rtems-O2-fomit-frame-pointers/cpukit/libfs/rfs'. For the posix 'rtems-posix-O2-fomit-frame-pointers/cpukit/libfs/rfs'
Well, I hope we don't have to get into much more than -O2/-Os on compile
options but that's generally the idea.  Multiple covoar passes over one
set of execution run logs.
>> It will not add to the build or test execution time. It will add to the report generation time. All views/categories can be generated from a single run.
> Can you re-run just the report phase or does this not make sense ?
That's what happens. We would just be re-running the covoar phase
for each category of symbols. With small symbol sets, it should be
fairly quick.

The question is the set of categories. :)

--joel
> Chris


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985