[PATCH] Coverage : Use '.o' files for coverage analysis

[Vijay Kumar Banerjee]

Use the Object files in cpukit/ instead of the static library
for Coverage analysis
---
 tester/rt/coverage.py | 27 --
 tester/rtems/testing/coverage/symbol-sets.ini | 90 +--
 2 files changed, 66 insertions(+), 51 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index c979332..55cb59a 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -244,13 +244,17 @@ class symbol_parser(object):
  symbol_config_path,
  symbol_select_path,
  symbol_set,
- build_dir):
+ build_dir,
+ bsp_name,
+ target):
 self.symbol_select_file = symbol_select_path
 self.symbol_file = symbol_config_path
 self.build_dir = build_dir
 self.symbol_sets = {}
 self.symbol_set = symbol_set
 self.ssets = []
+self.bsp_name = bsp_name
+self.target = target
 
 def parse(self):
 config = configparser.ConfigParser()
@@ -264,9 +268,13 @@ class symbol_parser(object):
 for sset in self.ssets:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+ss = self.symbol_sets[sset]
+ss = ss.replace('@BSP@', self.bsp_name)
+ss = ss.replace('@BUILD-TARGET@', self.target)
+self.symbol_sets[sset] = ss
 return self.ssets
 except:
-raise error.general('Symbol set parsing failed')
+raise error.general('Symbol set parsing failed for %s' % sset)
 
 def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
@@ -275,11 +283,15 @@ class symbol_parser(object):
 config.add_section('symbol-sets')
 config.set('symbol-sets', 'sets', sset)
 config.add_section(sset)
-config.set(sset, 'libraries', self.symbol_sets[sset])
+object_files = [o for o in os.listdir(self.symbol_sets[sset]) if 
o[-1] == 'o']
+object_paths = []
+for o in object_files:
+object_paths.append(path.join(self.symbol_sets[sset], o))
+config.set(sset, 'libraries', ','.join(object_paths))
 with open(self.symbol_select_file, 'w') as conf:
-config.write(conf)
+config.write(conf)
 except:
-raise error.general('symbol parser write failed')
+raise error.general('symbol parser write failed for %s' % sset)
 
 class covoar(object):
 '''
@@ -357,6 +369,7 @@ class coverage_run(object):
 self.report_format = self.macros['cov_report_format']
 self.symbol_set = symbol_set
 self.target = self.macros['target']
+self.bsp_name = self.macros['bsp'].split('-')[0]
 
 def run(self):
 try:
@@ -366,7 +379,9 @@ class coverage_run(object):
 parser = symbol_parser(self.symbol_config_path,
self.symbol_select_path,
self.symbol_set,
-   build_dir)
+   build_dir,
+   self.bsp_name,
+   self.target)
 symbol_sets = parser.parse()
 for sset in symbol_sets:
 parser.write_ini(sset)
diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
b/tester/rtems/testing/coverage/symbol-sets.ini
index 2685ef4..8f85533 100644
--- a/tester/rtems/testing/coverage/symbol-sets.ini
+++ b/tester/rtems/testing/coverage/symbol-sets.ini
@@ -29,50 +29,50 @@
 #
 
 [symbol-sets]
-sets = 
score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock
+sets = 
score,rtems,sapi,libdl,posix,librfs,libdosfs,libdevfs,libimfs,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock
 
 [libraries]
-score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
-rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
-sapi  = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a
-libdl = @BUILD-TARGET@/c/@BSP@/cpukit/libdl/libdl.a
-posix = @BUILD-TARGET@/c/@BSP@/cpukit/posix/libposix.a
-libirfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/librfs.a
-libdosfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdosfs.a
-libdevfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdevfs.a
-libimfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libimfs.a
-#libdefaultsfs = @BUiLD-TARGET@/c/@BSP@/cpukit/libfs/libdefaultfs.a
-#libjffs2  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libjffs2.a
-#dtc   = @BUILD-TARGET@/c/@BSP@/cpukit/libfdt/libfdt.a
-#libdrvmgr = @BUILD-TARGET@/c/@BSP@/cpukit/libdrvmgr/libdrvmgr.a
-#libi2c= 

Re: [PATCH] Coverage : Use '.o' files for coverage analysis

[Vijay Kumar Banerjee]

On Tue, Oct 16, 2018, 8:15 AM Chris Johns  wrote:

> Hi Vijay
>
> Thank you for the patch.
>
> On 13/10/2018 13:29, Vijay Kumar Banerjee wrote:
> > Use the Object files in cpukit/ instead of the static library
> > for Coverage analysis
>
> Are there any code changes in covoar or is the only change this patch?

a few lines can be removed from covoar as the script
is doing the job, but I wasn't sure that we wanted it removed from covoar
so I kept it untouched.

>
> > ---
> >  tester/rt/coverage.py | 27 --
> >  tester/rtems/testing/coverage/symbol-sets.ini | 90 +--
> >  2 files changed, 66 insertions(+), 51 deletions(-)
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > index c979332..55cb59a 100644
> > --- a/tester/rt/coverage.py
> > +++ b/tester/rt/coverage.py
> > @@ -244,13 +244,17 @@ class symbol_parser(object):
> >   symbol_config_path,
> >   symbol_select_path,
> >   symbol_set,
> > - build_dir):
> > + build_dir,
> > + bsp_name,
> > + target):
> >  self.symbol_select_file = symbol_select_path
> >  self.symbol_file = symbol_config_path
> >  self.build_dir = build_dir
> >  self.symbol_sets = {}
> >  self.symbol_set = symbol_set
> >  self.ssets = []
> > +self.bsp_name = bsp_name
> > +self.target = target
> >
> >  def parse(self):
> >  config = configparser.ConfigParser()
> > @@ -264,9 +268,13 @@ class symbol_parser(object):
> >  for sset in self.ssets:
> >  lib = path.join(self.build_dir, config.get('libraries',
> sset))
> >  self.symbol_sets[sset] = lib.encode('utf-8')
> > +ss = self.symbol_sets[sset]
> > +ss = ss.replace('@BSP@', self.bsp_name)
> > +ss = ss.replace('@BUILD-TARGET@', self.target)
> > +self.symbol_sets[sset] = ss
> >  return self.ssets
> >  except:
> > -raise error.general('Symbol set parsing failed')
> > +raise error.general('Symbol set parsing failed for %s' %
> sset)
>
> I put all values after the '%' in '()', that is "... %s' % (sset))".
>
Thanks.

>
> >
> >  def write_ini(self, symbol_set):
> >  config = configparser.ConfigParser()
> > @@ -275,11 +283,15 @@ class symbol_parser(object):
> >  config.add_section('symbol-sets')
> >  config.set('symbol-sets', 'sets', sset)
> >  config.add_section(sset)
> > -config.set(sset, 'libraries', self.symbol_sets[sset])
> > +object_files = [o for o in
> os.listdir(self.symbol_sets[sset]) if o[-1] == 'o']
> > +object_paths = []
> > +for o in object_files:
> > +object_paths.append(path.join(self.symbol_sets[sset],
> o))
> > +config.set(sset, 'libraries', ','.join(object_paths))
> >  with open(self.symbol_select_file, 'w') as conf:
> > -config.write(conf)
> > +config.write(conf)
> >  except:
> > -raise error.general('symbol parser write failed')
> > +raise error.general('symbol parser write failed for %s' %
> sset)
>
> Same here.
>
> Chris
>
> >
> >  class covoar(object):
> >  '''
> > @@ -357,6 +369,7 @@ class coverage_run(object):
> >  self.report_format = self.macros['cov_report_format']
> >  self.symbol_set = symbol_set
> >  self.target = self.macros['target']
> > +self.bsp_name = self.macros['bsp'].split('-')[0]
> >
> >  def run(self):
> >  try:
> > @@ -366,7 +379,9 @@ class coverage_run(object):
> >  parser = symbol_parser(self.symbol_config_path,
> > self.symbol_select_path,
> > self.symbol_set,
> > -   build_dir)
> > +   build_dir,
> > +   self.bsp_name,
> > +   self.target)
> >  symbol_sets = parser.parse()
> >  for sset in symbol_sets:
> >  parser.write_ini(sset)
> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
> b/tester/rtems/testing/coverage/symbol-se

[PATCH] Coverage : Use '.o' files for coverage analysis

[Vijay Kumar Banerjee]

Use the Object files in cpukit/ instead of the static library
for Coverage analysis
---
 tester/rt/coverage.py | 27 --
 tester/rtems/testing/coverage/symbol-sets.ini | 90 +--
 2 files changed, 66 insertions(+), 51 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index c979332..55cb59a 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -244,13 +244,17 @@ class symbol_parser(object):
  symbol_config_path,
  symbol_select_path,
  symbol_set,
- build_dir):
+ build_dir,
+ bsp_name,
+ target):
 self.symbol_select_file = symbol_select_path
 self.symbol_file = symbol_config_path
 self.build_dir = build_dir
 self.symbol_sets = {}
 self.symbol_set = symbol_set
 self.ssets = []
+self.bsp_name = bsp_name
+self.target = target
 
 def parse(self):
 config = configparser.ConfigParser()
@@ -264,9 +268,13 @@ class symbol_parser(object):
 for sset in self.ssets:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+ss = self.symbol_sets[sset]
+ss = ss.replace('@BSP@', self.bsp_name)
+ss = ss.replace('@BUILD-TARGET@', self.target)
+self.symbol_sets[sset] = ss
 return self.ssets
 except:
-raise error.general('Symbol set parsing failed')
+raise error.general('Symbol set parsing failed for %s' % sset)
 
 def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
@@ -275,11 +283,15 @@ class symbol_parser(object):
 config.add_section('symbol-sets')
 config.set('symbol-sets', 'sets', sset)
 config.add_section(sset)
-config.set(sset, 'libraries', self.symbol_sets[sset])
+object_files = [o for o in os.listdir(self.symbol_sets[sset]) if 
o[-1] == 'o']
+object_paths = []
+for o in object_files:
+object_paths.append(path.join(self.symbol_sets[sset], o))
+config.set(sset, 'libraries', ','.join(object_paths))
 with open(self.symbol_select_file, 'w') as conf:
-config.write(conf)
+config.write(conf)
 except:
-raise error.general('symbol parser write failed')
+raise error.general('symbol parser write failed for %s' % sset)
 
 class covoar(object):
 '''
@@ -357,6 +369,7 @@ class coverage_run(object):
 self.report_format = self.macros['cov_report_format']
 self.symbol_set = symbol_set
 self.target = self.macros['target']
+self.bsp_name = self.macros['bsp'].split('-')[0]
 
 def run(self):
 try:
@@ -366,7 +379,9 @@ class coverage_run(object):
 parser = symbol_parser(self.symbol_config_path,
self.symbol_select_path,
self.symbol_set,
-   build_dir)
+   build_dir,
+   self.bsp_name,
+   self.target)
 symbol_sets = parser.parse()
 for sset in symbol_sets:
 parser.write_ini(sset)
diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
b/tester/rtems/testing/coverage/symbol-sets.ini
index 2685ef4..8f85533 100644
--- a/tester/rtems/testing/coverage/symbol-sets.ini
+++ b/tester/rtems/testing/coverage/symbol-sets.ini
@@ -29,50 +29,50 @@
 #
 
 [symbol-sets]
-sets = 
score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock
+sets = 
score,rtems,sapi,libdl,posix,librfs,libdosfs,libdevfs,libimfs,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock
 
 [libraries]
-score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
-rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
-sapi  = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a
-libdl = @BUILD-TARGET@/c/@BSP@/cpukit/libdl/libdl.a
-posix = @BUILD-TARGET@/c/@BSP@/cpukit/posix/libposix.a
-libirfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/librfs.a
-libdosfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdosfs.a
-libdevfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdevfs.a
-libimfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libimfs.a
-#libdefaultsfs = @BUiLD-TARGET@/c/@BSP@/cpukit/libfs/libdefaultfs.a
-#libjffs2  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libjffs2.a
-#dtc   = @BUILD-TARGET@/c/@BSP@/cpukit/libfdt/libfdt.a
-#libdrvmgr = @BUILD-TARGET@/c/@BSP@/cpukit/libdrvmgr/libdrvmgr.a
-#libi2c= 

Re: [PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am

[Vijay Kumar Banerjee]

On Mon, 1 Oct 2018 at 11:22, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25/09/2018 07:58, Chris Johns wrote:
> > On 25/09/2018 15:30, Sebastian Huber wrote:
> >> On 25/09/2018 00:27, Chris Johns wrote:
> >> We would have to go from the symbol to the ELF file to the DWARF
> info of the
> >> compilation unit.
> > All info should be directly via the ELF and DWARF format. I do not
> know if we
> > need to reference the ELF symbol table or we can just use the DWARF
> CU data.
> > The
> > use of objdump should be avoided.
>  I only briefly look into this, but you have to go from the
> rld::symbols::symbol
>  to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot
> to add this
>  stuff.
> 
> >>> You could be right. The DWARF info will contain all symbols and more.
> >>>
> >>> Should these files move to the rtems.git repo?
> >> The *.ini files or which files?
> > Just the INI files, the files which describe the data.
> >
> >> I would leave the files where they are and fix
> >> the issues first. Afterwards I would think about moving files around
> across
> >> repositories.
> > Oh of course, that is fine and it makes sense. I would like to
> understand the
> > tasks and agree on them.
>
> This stalled my background work on general RTEMS improvements (in this
> case the build system). I think the path is clear. We use source tree
> path regular expressions to assign source files to categories. The
> source tree path is determined for each symbol by the DWARF compilation
> unit information. The categories are defined in an INI file in
> rtems-tools for now. Maybe later it is places somewhere else.
>
> I would like to continue now with the build system changes. This will
> break the coverage tool categories for some time.
>
> Is there some documentation on how I can use the coverage tool? Which
> BSP is recommended for test runs?
>
> There isn't proper documentation of this, but the following wiki page
has the instruction of how to run the coverage tool.
https://devel.rtems.org/wiki/GSoC/2018/coverage_analysis_toolset

The coverage tool worked properly with leon3.

-- 
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

I have filed a ticket with all the information.

https://devel.rtems.org/ticket/3515

On Sat, 1 Sep 2018 at 00:35, Joel Sherrill  wrote:

>
>
> On Fri, Aug 31, 2018 at 1:42 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>>
>> On Sat, 1 Sep 2018 at 00:01, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Fri, Aug 31, 2018, 12:44 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Hello,
>>>> I have listed all the specific exes for which covoar fails.
>>>> I have observed that covoar fails only for some specific exe for some
>>>> symbol-sets,
>>>> this was the reason for covoar not completing successfully. If we
>>>> exclude these exe,
>>>> covoar finishes successfully for the whole testsuites. So the
>>>> prolem has become more
>>>> specific now, we'll have to investigate for only these exe.
>>>>
>>>> Here's the list of all the symbol-sets that were failing, along with
>>>> the exe files that made them
>>>> trip.
>>>>
>>>> ---
>>>> posix 
>>>> sptests/spmutex01.exe
>>>> fstests/fsclose01.exe
>>>>
>>>> sapi 
>>>> sptests/spversion01.exe
>>>>
>>>> librfs 
>>>> fstests/mrfs_fserror.exe
>>>> fstests/mrfs_fsrdwr.exe
>>>> (all fstests/mrfs_*.exe fails)
>>>> fstests/fsrofs01.exe
>>>> libtests/flashdisk01.exe
>>>>
>>>> libdevnull 
>>>> sptests/sp21.exe
>>>> psxtests/psxmmap01.exe
>>>> tmtests/tm20.exe
>>>>
>>>> libblock 
>>>> fstests/fsbdpart01.exe
>>>> -
>>>>
>>>
>>> Thanks.
>>>
>>> Have you had a chance to try get with catch throw?
>>>
>>  I'm trying it now with posix and fsclose01.exe, here's what I see.
>>
>
> I think we need Chris to wake up and give us some feedback. The throw is
> using
> rld::error.
>
> My guess is that something in those executables is not making rld happy.
> #4 is the line of the following line of code in covoar.cc:
>
> // Load the objdump for the symbols in this executable.
> objdumpProcessor->load( exe, objdumpFile, err );
>   }
>
> That's the loop loading the executables. Something in each of these exes
> is not making the underlying ELF/DWARF code happy.
>
> Hopefully Chris will wake up fresh on a nice Australian Saturday and
> have an answer. :)
>
>
>
>>
>> 
>> Catchpoint 1 (exception thrown), 0x77ad7f51 in
>> __cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80,
>> tinfo=tinfo@entry=0x488a70 , 
>> dest=dest@entry=0x40f980
>> )
>> at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:78
>> 78   PROBE2 (throw, obj, tinfo);
>> (gdb) bt
>> #0  0x77ad7f51 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80,
>> tinfo=tinfo@entry=0x488a70 ,
>> dest=dest@entry=0x40f980 ) at
>> ../../../../libstdc++-v3/libsupc++/eh_throw.cc:78
>> #1  0x00405926 in Coverage::ExecutableInfo::findCoverageMap
>> (this=, symbolName="wait")
>> #2  0x0041bc1d in
>> Coverage::finalizeSymbol(Coverage::ExecutableInfo*,
>> std::__cxx11::basic_string,
>> std::allocator >&,
>> std::__cxx11::list> std::allocator >)
>> () at ../tester/covoar/ObjdumpProcessor.cc:35
>>
> #3  0x0041c9e6 in
>> Coverage::ObjdumpProcessor::load(Coverage::ExecutableInfo*,
>> rld::process::tempfile&, rld::process::tempfile&) ()
>> at /usr/include/c++/8/new:169
>> #4  0x0040e058 in covoar(int, char**) () at
>> ../tester/covoar/covoar.cc:381
>> #5  0x0040bacc in main () at ../tester/covoar/covoar.cc:563
>> #6  0x770fd1bb in __libc_start_main (main=0x40b9b0 ,
>> argc=11, argv=0x7fffd4b8, init=, fini=,
>> rtld_fini=, stack_end=0x7fffd4a8) at
>> ../csu/libc-start.c:308
>> #7  0x0040c32a in _start () at ../tester/covoar/covoar.cc:593
>>
>> 
>>
>>>
>>>>
>>>> On Wed, 22 Aug 2018 at 21:11, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> I will send the attachment offlist as it's too big for the list.
>>>>> On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee <

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

On Sat, 1 Sep 2018 at 00:01, Joel Sherrill  wrote:

>
>
> On Fri, Aug 31, 2018, 12:44 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>> I have listed all the specific exes for which covoar fails.
>> I have observed that covoar fails only for some specific exe for some
>> symbol-sets,
>> this was the reason for covoar not completing successfully. If we exclude
>> these exe,
>> covoar finishes successfully for the whole testsuites. So the prolem has
>> become more
>> specific now, we'll have to investigate for only these exe.
>>
>> Here's the list of all the symbol-sets that were failing, along with the
>> exe files that made them
>> trip.
>>
>> ---
>> posix 
>> sptests/spmutex01.exe
>> fstests/fsclose01.exe
>>
>> sapi 
>> sptests/spversion01.exe
>>
>> librfs 
>> fstests/mrfs_fserror.exe
>> fstests/mrfs_fsrdwr.exe
>> (all fstests/mrfs_*.exe fails)
>> fstests/fsrofs01.exe
>> libtests/flashdisk01.exe
>>
>> libdevnull 
>> sptests/sp21.exe
>> psxtests/psxmmap01.exe
>> tmtests/tm20.exe
>>
>> libblock 
>> fstests/fsbdpart01.exe
>> -
>>
>
> Thanks.
>
> Have you had a chance to try get with catch throw?
>
 I'm trying it now with posix and fsclose01.exe, here's what I see.


Catchpoint 1 (exception thrown), 0x77ad7f51 in
__cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80,
tinfo=tinfo@entry=0x488a70 ,
dest=dest@entry=0x40f980
)
at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:78
78   PROBE2 (throw, obj, tinfo);
(gdb) bt
#0  0x77ad7f51 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80,
tinfo=tinfo@entry=0x488a70 ,
dest=dest@entry=0x40f980 ) at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:78
#1  0x00405926 in Coverage::ExecutableInfo::findCoverageMap
(this=, symbolName="wait")
#2  0x0041bc1d in
Coverage::finalizeSymbol(Coverage::ExecutableInfo*,
std::__cxx11::basic_string,
std::allocator >&,
std::__cxx11::list >)
() at ../tester/covoar/ObjdumpProcessor.cc:35
#3  0x0041c9e6 in
Coverage::ObjdumpProcessor::load(Coverage::ExecutableInfo*,
rld::process::tempfile&, rld::process::tempfile&) ()
at /usr/include/c++/8/new:169
#4  0x0040e058 in covoar(int, char**) () at
../tester/covoar/covoar.cc:381
#5  0x0040bacc in main () at ../tester/covoar/covoar.cc:563
#6  0x770fd1bb in __libc_start_main (main=0x40b9b0 , argc=11,
argv=0x7fffd4b8, init=, fini=,
rtld_fini=, stack_end=0x7fffd4a8) at
../csu/libc-start.c:308
#7  0x0040c32a in _start () at ../tester/covoar/covoar.cc:593



>
>>
>> On Wed, 22 Aug 2018 at 21:11, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I will send the attachment offlist as it's too big for the list.
>>> On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> The coverage for whole testsuite completed successfully,
>>>> I have attached the zip file here and also included the js and css
>>>> files in it.
>>>>
>>>> coverage didn't complete for the following symbol-set libraries and was
>>>> returning,
>>>> covoar error 10
>>>>
>>>> * libsapi.a
>>>> * libposix.a
>>>> * librfs.a
>>>> * libcsupport.a
>>>> * libdevnull.a
>>>> * libblock.a
>>>>
>>>>
>>>> On Wed, 22 Aug 2018 at 10:22, Chris Johns  wrote:
>>>>
>>>>> On 22/08/2018 14:41, Joel Sherrill wrote:
>>>>> > On Tue, Aug 21, 2018, 10:26 PM Chris Johns >>>> > <mailto:chr...@rtems.org>> wrote:
>>>>> >
>>>>> > On 22/08/2018 09:29, Joel Sherrill wrote:
>>>>> > > On Tue, Aug 21, 2018, 4:05 PM Vijay Kumar Banerjee
>>>>> > mailto:vijaykumar9...@gmail.com>
>>>>> > > <mailto:vijaykumar9...@gmail.com >>>> vijaykumar9...@gmail.com>>> wrote:
>>>>> > > On Wed, 22 Aug 2018 at 01:55, Joel Sherrill <
>>>>> j...@rtems.org
>>>>> > <mailto:j...@rtems.org>
>>>>> > > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote:
>>>>> > >
>>>>> > > How long is covoar taking for the entire set?
>>>>> > >

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

Hello,
I have listed all the specific exes for which covoar fails.
I have observed that covoar fails only for some specific exe for some
symbol-sets,
this was the reason for covoar not completing successfully. If we exclude
these exe,
covoar finishes successfully for the whole testsuites. So the prolem has
become more
specific now, we'll have to investigate for only these exe.

Here's the list of all the symbol-sets that were failing, along with the
exe files that made them
trip.

---
posix 
sptests/spmutex01.exe
fstests/fsclose01.exe

sapi 
sptests/spversion01.exe

librfs 
fstests/mrfs_fserror.exe
fstests/mrfs_fsrdwr.exe
(all fstests/mrfs_*.exe fails)
fstests/fsrofs01.exe
libtests/flashdisk01.exe

libdevnull 
sptests/sp21.exe
psxtests/psxmmap01.exe
tmtests/tm20.exe

libblock 
fstests/fsbdpart01.exe
-


On Wed, 22 Aug 2018 at 21:11, Vijay Kumar Banerjee 
wrote:

> I will send the attachment offlist as it's too big for the list.
> On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> The coverage for whole testsuite completed successfully,
>> I have attached the zip file here and also included the js and css files
>> in it.
>>
>> coverage didn't complete for the following symbol-set libraries and was
>> returning,
>> covoar error 10
>>
>> * libsapi.a
>> * libposix.a
>> * librfs.a
>> * libcsupport.a
>> * libdevnull.a
>> * libblock.a
>>
>>
>> On Wed, 22 Aug 2018 at 10:22, Chris Johns  wrote:
>>
>>> On 22/08/2018 14:41, Joel Sherrill wrote:
>>> > On Tue, Aug 21, 2018, 10:26 PM Chris Johns >> > <mailto:chr...@rtems.org>> wrote:
>>> >
>>> > On 22/08/2018 09:29, Joel Sherrill wrote:
>>> > > On Tue, Aug 21, 2018, 4:05 PM Vijay Kumar Banerjee
>>> > mailto:vijaykumar9...@gmail.com>
>>> > > <mailto:vijaykumar9...@gmail.com >> vijaykumar9...@gmail.com>>> wrote:
>>> > > On Wed, 22 Aug 2018 at 01:55, Joel Sherrill >> > <mailto:j...@rtems.org>
>>> > > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote:
>>> > >
>>> > > How long is covoar taking for the entire set?
>>> > >
>>> > > It works great. this is what `time` says
>>> > > 
>>> > > real17m49.887s
>>> > > user14m25.620s
>>> > > sys0m37.847s
>>> > > 
>>> > >
>>> > > What speed and type of processor do you have?
>>> > >
>>> >
>>> > The program is single threaded so the preprocessing of each
>>> executable is
>>> > sequential. Memory usage is reasonable so there is no swapping.
>>> >
>>> > Running covoar from the command line on a box with:
>>> >
>>> >  hw.machine: amd64
>>> >  hw.model: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
>>> >  hw.ncpu: 16
>>> >  hw.machine_arch: amd64
>>> >
>>> > plus 32G of memory has a time of:
>>> >
>>> >   366.32 real   324.97 user41.33 sys
>>> >
>>> > The approximate time break down is:
>>> >
>>> >  ELF/DWARF loading  : 110s (1m50s)
>>> >  Objdump: 176s (2m56s)
>>> >  Processing :  80s (1m20s)
>>> >
>>> >
>>> > I don't mind this execution time for the near future. It is far from
>>> obscene
>>> > after building and running 600 tests.
>>>
>>> Yeah, there are other things we need to do first.
>>>
>>> > The DWARF loading is not optimised and I load all source line to
>>> address maps
>>> > and all functions rather that selectively scanning for specific
>>> names at the
>>> > DWARF level. It is not clear to me scanning would be better or
>>> faster.
>>> >
>>> > I doubt it is worth the effort. There should be few symbols in an exe
>>> we don't
>>> > care about. Especially once we start to worry about libc and libm.
>>>
>>> Yeah, this is what I thought at the start.
>>>
>>> > My hope
>>> > is moving to Capstone would help lower or remove the objdump
>>> overhead. Then
>>> > there is threading for the loading.
>

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

I will send the attachment offlist as it's too big for the list.
On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee 
wrote:

> The coverage for whole testsuite completed successfully,
> I have attached the zip file here and also included the js and css files
> in it.
>
> coverage didn't complete for the following symbol-set libraries and was
> returning,
> covoar error 10
>
> * libsapi.a
> * libposix.a
> * librfs.a
> * libcsupport.a
> * libdevnull.a
> * libblock.a
>
>
> On Wed, 22 Aug 2018 at 10:22, Chris Johns  wrote:
>
>> On 22/08/2018 14:41, Joel Sherrill wrote:
>> > On Tue, Aug 21, 2018, 10:26 PM Chris Johns > > <mailto:chr...@rtems.org>> wrote:
>> >
>> > On 22/08/2018 09:29, Joel Sherrill wrote:
>> > > On Tue, Aug 21, 2018, 4:05 PM Vijay Kumar Banerjee
>> > mailto:vijaykumar9...@gmail.com>
>> > > <mailto:vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com>>>
>> wrote:
>> > > On Wed, 22 Aug 2018 at 01:55, Joel Sherrill > > <mailto:j...@rtems.org>
>> > > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote:
>> > >
>> > > How long is covoar taking for the entire set?
>> > >
>> > > It works great. this is what `time` says
>> > > 
>> > > real17m49.887s
>> > > user14m25.620s
>> > > sys0m37.847s
>> > > 
>> > >
>> > > What speed and type of processor do you have?
>> > >
>> >
>> > The program is single threaded so the preprocessing of each
>> executable is
>> > sequential. Memory usage is reasonable so there is no swapping.
>> >
>> > Running covoar from the command line on a box with:
>> >
>> >  hw.machine: amd64
>> >  hw.model: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
>> >  hw.ncpu: 16
>> >  hw.machine_arch: amd64
>> >
>> > plus 32G of memory has a time of:
>> >
>> >   366.32 real   324.97 user41.33 sys
>> >
>> > The approximate time break down is:
>> >
>> >  ELF/DWARF loading  : 110s (1m50s)
>> >  Objdump: 176s (2m56s)
>> >  Processing :  80s (1m20s)
>> >
>> >
>> > I don't mind this execution time for the near future. It is far from
>> obscene
>> > after building and running 600 tests.
>>
>> Yeah, there are other things we need to do first.
>>
>> > The DWARF loading is not optimised and I load all source line to
>> address maps
>> > and all functions rather that selectively scanning for specific
>> names at the
>> > DWARF level. It is not clear to me scanning would be better or
>> faster.
>> >
>> > I doubt it is worth the effort. There should be few symbols in an exe
>> we don't
>> > care about. Especially once we start to worry about libc and libm.
>>
>> Yeah, this is what I thought at the start.
>>
>> > My hope
>> > is moving to Capstone would help lower or remove the objdump
>> overhead. Then
>> > there is threading for the loading.
>> >
>> > > I don't recall it taking near this long in the past. I used to
>> run it as
>> > part of
>> > > development.
>> >
>> > The objdump processing is simpler than before so I suspect the time
>> would have
>> > been at least 4 minutes.
>> >
>> > > But we may have more tests and the code has changed.
>> >
>> > I think having more tests is the dominant factor.
>> >
>> > > Reading dwarf
>> > > with the file open/closes, etc just may be more expensive than
>> parsing the
>> > text
>> > > files.
>> >
>> > The reading DWARF is a cost and at the moment it is not optimised
>> but it is only
>> > a cost because we still parse the objdump data. I think opening and
>> closing
>> > files is not a factor.
>> >
>> > The parsing the objdump is the largest component of time. Maybe
>> using Capstone
>> > with the ELF files will help.
>> >
>> > > But it is more accurate and lays the groundwork.for more types of
>> analysis.
>> >
>> > Yes and think this i

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

On Wed, 22 Aug 2018 at 01:55, Joel Sherrill  wrote:

>
>
> On Tue, Aug 21, 2018, 1:59 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Tue, Aug 21, 2018, 7:34 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Tue, Aug 21, 2018 at 2:14 AM, Chris Johns  wrote:
>>>
>>>> On 21/08/2018 16:55, Vijay Kumar Banerjee wrote:
>>>> > I tried running coverage with this latest
>>>> > master, covoar is taking up all the memory (7 GB) including the swap
>>>> (7.6 GB)
>>>> > and after a while, still gets killed. :(
>>>>
>>>> I ran rtems-test and created the .cov files and then ran covoar from
>>>> the command
>>>> line (see below). Looking at top while it is running I see covoar
>>>> topping out
>>>> with a size around 1430M. The size is pretty static once the "Loading
>>>> symbol
>>>> sets:" is printed.
>>>>
>>>> I have run covoar under valgrind with a smaller number of executables
>>>> and made
>>>> sure all the allocations are ok.
>>>>
>>>> I get a number of size mismatch messages related the inline functions
>>>> but that
>>>> is a known issue.
>>>>
>>>> > can there be something wrong with my environment?
>>>>
>>>> I have no idea.
>>>>
>>>> > I tried running it on a different system,
>>>> > coverage did run for the whole testsuite for score and rtems only.
>>>> > (I mentioned the symbols as argument to --coverage)
>>>> > but it  doesn't run for all the symbol-sets, strange.
>>>>
>>>> I am not running coverage via the rtems-test command. I have been
>>>> testing at the
>>>> covoar command line.
>>>>
>>>> Can you please try a variant of:
>>>>
>>>>  /opt/work/chris/rtems/rt/rtems-tools.git/build/tester/covoar/covoar \
>>>>  -v \
>>>>  -S
>>>>
>>>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
>>>> \
>>>>  -O /opt/work/chris/rtems/kernel/bsps/leon3/leon3-qemu-coverage/score \
>>>>  -E
>>>>
>>>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/Explanations.txt
>>>> \
>>>>  -p RTEMS-5 `find . -name \*.exe`
>>>> ?
>>>>
>>>> I have top running at the same time. The foot print grows while the
>>>> DWARF info
>>>> and .cov files are loaded which is
>>>>
>>>
>>> Vijay .. I would add to make sure the gcov processing is turned off for
>>> now.
>>>
>> it's turned off. :)
>>
>
> Just checking. That code isn't ready yet. :)
>
>>
>> After a lot of different attempts I realized that I just needed to waf
>> build after pulling the new changes. Sorry about that.
>>
>
> Lol. It is always the dumb things.
>
> It did run successfully !
>> I'm now running coverage with rtems-test for the whole testsuite, I will
>> be reporting about it soon :)
>>
>
> How long is covoar taking for the entire set?
>
> It works great. this is what `time` says

real 17m49.887s
user 14m25.620s
sys 0m37.847s


> Not that I am complaining, it takes minutes to do a doc build these days
>
>
>>>> Thanks
>>>> Chris
>>>>
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

On Tue, Aug 21, 2018, 7:34 PM Joel Sherrill  wrote:

>
>
> On Tue, Aug 21, 2018 at 2:14 AM, Chris Johns  wrote:
>
>> On 21/08/2018 16:55, Vijay Kumar Banerjee wrote:
>> > I tried running coverage with this latest
>> > master, covoar is taking up all the memory (7 GB) including the swap
>> (7.6 GB)
>> > and after a while, still gets killed. :(
>>
>> I ran rtems-test and created the .cov files and then ran covoar from the
>> command
>> line (see below). Looking at top while it is running I see covoar topping
>> out
>> with a size around 1430M. The size is pretty static once the "Loading
>> symbol
>> sets:" is printed.
>>
>> I have run covoar under valgrind with a smaller number of executables and
>> made
>> sure all the allocations are ok.
>>
>> I get a number of size mismatch messages related the inline functions but
>> that
>> is a known issue.
>>
>> > can there be something wrong with my environment?
>>
>> I have no idea.
>>
>> > I tried running it on a different system,
>> > coverage did run for the whole testsuite for score and rtems only.
>> > (I mentioned the symbols as argument to --coverage)
>> > but it  doesn't run for all the symbol-sets, strange.
>>
>> I am not running coverage via the rtems-test command. I have been testing
>> at the
>> covoar command line.
>>
>> Can you please try a variant of:
>>
>>  /opt/work/chris/rtems/rt/rtems-tools.git/build/tester/covoar/covoar \
>>  -v \
>>  -S
>>
>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
>> \
>>  -O /opt/work/chris/rtems/kernel/bsps/leon3/leon3-qemu-coverage/score \
>>  -E
>>
>> /opt/work/chris/rtems/rt/rtems-tools.git/tester/rtems/testing/coverage/Explanations.txt
>> \
>>  -p RTEMS-5 `find . -name \*.exe`
>> ?
>>
>> I have top running at the same time. The foot print grows while the DWARF
>> info
>> and .cov files are loaded which is
>>
>
> Vijay .. I would add to make sure the gcov processing is turned off for
> now.
>
it's turned off. :)

After a lot of different attempts I realized that I just needed to waf
build after pulling the new changes. Sorry about that.
It did run successfully !
I'm now running coverage with rtems-test for the whole testsuite, I will be
reporting about it soon :)

>
>> Thanks
>> Chris
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: covoar SIGKILL Investigation

[Vijay Kumar Banerjee]

I tried running coverage with this latest
master, covoar is taking up all the memory (7 GB) including the swap (7.6
GB)
and after a while, still gets killed. :(
can there be something wrong with my environment?

I tried running it on a different system,
coverage did run for the whole testsuite for score and rtems only.
(I mentioned the symbols as argument to --coverage)
but it  doesn't run for all the symbol-sets, strange.

On Tue, Aug 21, 2018, 10:17 AM Chris Johns  wrote:

> On 15/08/2018 19:13, Chris Johns wrote:
> > On 15/8/18 2:47 am, Joel Sherrill wrote:
> >>
> >> Ideas appreciated on how to debug this enough to find
> >> the cause.
> >>
> >
> > Does the attached patch help?
> >
>
> I have pushed this patch. I tested it on more than 500 executables on
> FreeBSD
> and the process was not killed.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

ping :)

On 3 August 2018 at 03:15, Vijay Kumar Banerjee 
wrote:

> Hello,
>
> If you find some time, please do a final review of this patch and provide
> suggestions if it's not mergeable yet :)
>
> There are only three days left, I seek some advice on the wrapup work on
> coverage
> analysis . The current status is :
>
> * This patch adds support to generate separate report for each symbol-sets.
>
> * I sent a patch a day ago with the symbol-sets and the respective
> libraray
>   addresses added to the symbol-sets.ini file. I have also attached a
> screenshot of the report.
>   Joel, does the report look good to you ?
>   What are the next steps to get the reports published ? Is it intended to
> be a
>   post GSoC work ?
>
> * I have completed the dumper for gcno files. There are still more
> understanding
>   needed to make sense out of the data, but all the data can be dumped in
> a human
>   readable format now. Please have a look at the  generated txt file.
>   https://github.com/thelunatic/gcno_dumper/blob/master/gcno_dump.txt
> <https://github.com/thelunatic/gcno_dumper/blob/master/gcno_dump.txt>
>
> *  Any other suggestions ?
>
> Thanks
> --vijayk
>
> On 30 July 2018 at 22:55, Vijay Kumar Banerjee 
> wrote:
>
>> Invoke covoar multiple times from the script to generate separate
>> reports for each symbol-set.
>> ---
>>  tester/rt/coverage.py | 38 ++
>>  1 file changed, 18 insertions(+), 20 deletions(-)
>>
>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> index 7dd5002..c979332 100644
>> --- a/tester/rt/coverage.py
>> +++ b/tester/rt/coverage.py
>> @@ -99,8 +99,8 @@ class summary:
>>  return line.strip().split(' ')[0]
>>
>>  class report_gen_html:
>> -def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
>> -self.symbol_sets_list = ['score']
>> +def __init__(self, symbol_sets, build_dir, rtdir, bsp):
>> +self.symbol_sets = symbol_sets
>>  self.build_dir = build_dir
>>  self.partial_reports_files = list(['index.html', 'summary.txt'])
>>  self.number_of_columns = 1
>> @@ -109,7 +109,7 @@ class report_gen_html:
>>
>>  def _find_partial_reports(self):
>>  partial_reports = {}
>> -for symbol_set in self.symbol_sets_list:
>> +for symbol_set in self.symbol_sets:
>>  set_summary = summary(path.join(self.bsp + "-coverage",
>>  symbol_set))
>>  set_summary.parse()
>> @@ -204,7 +204,7 @@ class report_gen_html:
>>  def add_covoar_src_path(self):
>>  table_js_path = path.join(self.covoar_src_path, 'table.js')
>>  covoar_css_path = path.join(self.covoar_src_path, 'covoar.css')
>> -for symbol_set in self.symbol_sets_list:
>> +for symbol_set in self.symbol_sets:
>>  symbol_set_dir = path.join(self.build_dir,
>> self.bsp + '-coverage',
>> symbol_set)
>>  html_files = os.listdir(symbol_set_dir)
>> @@ -264,27 +264,23 @@ class symbol_parser(object):
>>  for sset in self.ssets:
>>  lib = path.join(self.build_dir, config.get('libraries',
>> sset))
>>  self.symbol_sets[sset] = lib.encode('utf-8')
>> +return self.ssets
>>  except:
>>  raise error.general('Symbol set parsing failed')
>>
>> -def _write_ini(self):
>> +def write_ini(self, symbol_set):
>>  config = configparser.ConfigParser()
>>  try:
>> -sets = ', '.join(self.symbol_sets.keys())
>> +sset = symbol_set
>>  config.add_section('symbol-sets')
>> -config.set('symbol-sets', 'sets', sets)
>> -for key in self.symbol_sets.keys():
>> -config.add_section(key)
>> -config.set(key, 'libraries', self.symbol_sets[key])
>> +config.set('symbol-sets', 'sets', sset)
>> +config.add_section(sset)
>> +config.set(sset, 'libraries', self.symbol_sets[sset])
>>  with open(self.symbol_select_file, 'w') as conf:
>>  config.write(conf)
>>  except:
>>  raise error.general('symbol parser write failed')
>>
>> -def run(self):
>> -self.parse()
>> -self._write_ini()
>> -
>>  class covoar(object):
>>  '''
&

Re: [PATCH v2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Hello,

If you find some time, please do a final review of this patch and provide
suggestions if it's not mergeable yet :)

There are only three days left, I seek some advice on the wrapup work on
coverage
analysis . The current status is :

* This patch adds support to generate separate report for each symbol-sets.

* I sent a patch a day ago with the symbol-sets and the respective libraray
  addresses added to the symbol-sets.ini file. I have also attached a
screenshot of the report.
  Joel, does the report look good to you ?
  What are the next steps to get the reports published ? Is it intended to
be a
  post GSoC work ?

* I have completed the dumper for gcno files. There are still more
understanding
  needed to make sense out of the data, but all the data can be dumped in a
human
  readable format now. Please have a look at the  generated txt file.
  https://github.com/thelunatic/gcno_dumper/blob/master/gcno_dump.txt
<https://github.com/thelunatic/gcno_dumper/blob/master/gcno_dump.txt>

*  Any other suggestions ?

Thanks
--vijayk

On 30 July 2018 at 22:55, Vijay Kumar Banerjee 
wrote:

> Invoke covoar multiple times from the script to generate separate
> reports for each symbol-set.
> ---
>  tester/rt/coverage.py | 38 ++
>  1 file changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> index 7dd5002..c979332 100644
> --- a/tester/rt/coverage.py
> +++ b/tester/rt/coverage.py
> @@ -99,8 +99,8 @@ class summary:
>  return line.strip().split(' ')[0]
>
>  class report_gen_html:
> -def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
> -self.symbol_sets_list = ['score']
> +def __init__(self, symbol_sets, build_dir, rtdir, bsp):
> +self.symbol_sets = symbol_sets
>  self.build_dir = build_dir
>  self.partial_reports_files = list(['index.html', 'summary.txt'])
>  self.number_of_columns = 1
> @@ -109,7 +109,7 @@ class report_gen_html:
>
>  def _find_partial_reports(self):
>  partial_reports = {}
> -for symbol_set in self.symbol_sets_list:
> +for symbol_set in self.symbol_sets:
>  set_summary = summary(path.join(self.bsp + "-coverage",
>  symbol_set))
>  set_summary.parse()
> @@ -204,7 +204,7 @@ class report_gen_html:
>  def add_covoar_src_path(self):
>  table_js_path = path.join(self.covoar_src_path, 'table.js')
>  covoar_css_path = path.join(self.covoar_src_path, 'covoar.css')
> -for symbol_set in self.symbol_sets_list:
> +for symbol_set in self.symbol_sets:
>  symbol_set_dir = path.join(self.build_dir,
> self.bsp + '-coverage', symbol_set)
>  html_files = os.listdir(symbol_set_dir)
> @@ -264,27 +264,23 @@ class symbol_parser(object):
>  for sset in self.ssets:
>  lib = path.join(self.build_dir, config.get('libraries',
> sset))
>  self.symbol_sets[sset] = lib.encode('utf-8')
> +return self.ssets
>  except:
>  raise error.general('Symbol set parsing failed')
>
> -def _write_ini(self):
> +def write_ini(self, symbol_set):
>  config = configparser.ConfigParser()
>  try:
> -sets = ', '.join(self.symbol_sets.keys())
> +sset = symbol_set
>  config.add_section('symbol-sets')
> -config.set('symbol-sets', 'sets', sets)
> -for key in self.symbol_sets.keys():
> -config.add_section(key)
> -config.set(key, 'libraries', self.symbol_sets[key])
> +config.set('symbol-sets', 'sets', sset)
> +config.add_section(sset)
> +config.set(sset, 'libraries', self.symbol_sets[sset])
>  with open(self.symbol_select_file, 'w') as conf:
>  config.write(conf)
>  except:
>  raise error.general('symbol parser write failed')
>
> -def run(self):
> -self.parse()
> -self._write_ini()
> -
>  class covoar(object):
>  '''
>  Covoar runner
> @@ -371,20 +367,22 @@ class coverage_run(object):
> self.symbol_select_path,
> self.symbol_set,
> build_dir)
> -parser.run()
> -covoar_runner = covoar(self.test_dir, self.symbol_select_path,
> +symbol_sets = parser.parse()
> +for sset in symbol_sets:
> +parser.write_ini(sset)
> +covoar_runner = covoar(self.test

[PATCH v2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

---
 tester/rtems/testing/coverage/symbol-sets.ini | 48 +--
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
b/tester/rtems/testing/coverage/symbol-sets.ini
index a2ec7bc..aac0b9b 100644
--- a/tester/rtems/testing/coverage/symbol-sets.ini
+++ b/tester/rtems/testing/coverage/symbol-sets.ini
@@ -29,8 +29,50 @@
 #
 
 [symbol-sets]
-sets = score,rtems
+sets = 
score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock
 
 [libraries]
-score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
-rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
+rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+sapi  = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a
+libdl = @BUILD-TARGET@/c/@BSP@/cpukit/libdl/libdl.a 
+posix = @BUILD-TARGET@/c/@BSP@/cpukit/posix/libposix.a
+libirfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/librfs.a
+libdosfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdosfs.a
+libdevfs  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdevfs.a
+libimfs   = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libimfs.a
+#libdefaultsfs = @BUiLD-TARGET@/c/@BSP@/cpukit/libfs/libdefaultfs.a
+#libjffs2  = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libjffs2.a
+#dtc   = @BUILD-TARGET@/c/@BSP@/cpukit/libfdt/libfdt.a
+#libdrvmgr = @BUILD-TARGET@/c/@BSP@/cpukit/libdrvmgr/libdrvmgr.a
+#libi2c= @BUILD-TARGET@/c/@BSP@/cpukit/libi2c/libi2c.a 
+libcsupport   = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a
+libbspcmdline = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libbspcmdline.a
+libcpuuse = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libcpuuse.a
+libstackchk   = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libstackchk.a
+libfsmount= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libfsmount.a
+libstringto   = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libstringto.a
+libdevnull= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdevnull.a
+libdumpbuf= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdumpbuf.a
+#libcapture= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libcapture.a
+#libdummy  = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdummy.a
+#libmonitor= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmonitor.a
+#libmouse  = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmouse.a
+#libmw-fb  = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmw-fb.a
+#libredirector = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libredirector.a
+#librtemsfdt   = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/librtemsfdt.a
+#libserdbg = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libserdbg.a
+#libshell  = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libshell.a
+#libtestsupport= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libtestsupport.a
+#libuntar  = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libuntar.a
+#libutf8proc   = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libutf8proc.a
+#libuuid   = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libuuid.a
+#libxz = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libxz.a
+libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
+#libpci= @BUILD-TARGET@/c/@BSP@/cpukit/libpci/libpci.a
+#librpc= @BUILD-TARGET@/c/@BSP@/cpukit/librpc/librpc.a
+#libxdr= @BUILD-TARGET@/c/@BSP@/cpukit/librpc/libxdr.a
+#libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
+#libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
+#libstdthreads = @BUILD-TARGET@/c/@BSP@/cpukit/libstdthreads/libstdthreads.a
+#zlib  = @BUILD-TARGET@/c/@BSP@/cpukit/zlib/libz.a
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Invoke covoar multiple times from the script to generate separate
reports for each symbol-set.
---
 tester/rt/coverage.py | 38 ++
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 7dd5002..c979332 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -99,8 +99,8 @@ class summary:
 return line.strip().split(' ')[0]
 
 class report_gen_html:
-def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
-self.symbol_sets_list = ['score']
+def __init__(self, symbol_sets, build_dir, rtdir, bsp):
+self.symbol_sets = symbol_sets
 self.build_dir = build_dir
 self.partial_reports_files = list(['index.html', 'summary.txt'])
 self.number_of_columns = 1
@@ -109,7 +109,7 @@ class report_gen_html:
 
 def _find_partial_reports(self):
 partial_reports = {}
-for symbol_set in self.symbol_sets_list:
+for symbol_set in self.symbol_sets:
 set_summary = summary(path.join(self.bsp + "-coverage",
 symbol_set))
 set_summary.parse()
@@ -204,7 +204,7 @@ class report_gen_html:
 def add_covoar_src_path(self):
 table_js_path = path.join(self.covoar_src_path, 'table.js')
 covoar_css_path = path.join(self.covoar_src_path, 'covoar.css')
-for symbol_set in self.symbol_sets_list:
+for symbol_set in self.symbol_sets:
 symbol_set_dir = path.join(self.build_dir,
self.bsp + '-coverage', symbol_set)
 html_files = os.listdir(symbol_set_dir)
@@ -264,27 +264,23 @@ class symbol_parser(object):
 for sset in self.ssets:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+return self.ssets
 except:
 raise error.general('Symbol set parsing failed')
 
-def _write_ini(self):
+def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
 try:
-sets = ', '.join(self.symbol_sets.keys())
+sset = symbol_set
 config.add_section('symbol-sets')
-config.set('symbol-sets', 'sets', sets)
-for key in self.symbol_sets.keys():
-config.add_section(key)
-config.set(key, 'libraries', self.symbol_sets[key])
+config.set('symbol-sets', 'sets', sset)
+config.add_section(sset)
+config.set(sset, 'libraries', self.symbol_sets[sset])
 with open(self.symbol_select_file, 'w') as conf:
 config.write(conf)
 except:
 raise error.general('symbol parser write failed')
 
-def run(self):
-self.parse()
-self._write_ini()
-
 class covoar(object):
 '''
 Covoar runner
@@ -371,20 +367,22 @@ class coverage_run(object):
self.symbol_select_path,
self.symbol_set,
build_dir)
-parser.run()
-covoar_runner = covoar(self.test_dir, self.symbol_select_path,
+symbol_sets = parser.parse()
+for sset in symbol_sets:
+parser.write_ini(sset)
+covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace)
-covoar_runner.run('score', self.symbol_select_path)
-self._generate_reports();
+covoar_runner.run(sset, self.symbol_select_path)
+self._generate_reports(symbol_sets);
 self._summarize();
 finally:
 self._cleanup();
 
-def _generate_reports(self):
+def _generate_reports(self, symbol_sets):
 log.notice('Coverage generating reports')
 if self.report_format == 'html':
-report = report_gen_html(self.symbol_sets,
+report = report_gen_html(symbol_sets,
  self.build_dir,
  self.rtdir,
  self.macros['bsp'])
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v4] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Invoke covoar multiple times from the script to generate separate
reports for each symbol-set.
---
 tester/rt/coverage.py | 38 ++
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 7dd5002..c979332 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -99,8 +99,8 @@ class summary:
 return line.strip().split(' ')[0]
 
 class report_gen_html:
-def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
-self.symbol_sets_list = ['score']
+def __init__(self, symbol_sets, build_dir, rtdir, bsp):
+self.symbol_sets = symbol_sets
 self.build_dir = build_dir
 self.partial_reports_files = list(['index.html', 'summary.txt'])
 self.number_of_columns = 1
@@ -109,7 +109,7 @@ class report_gen_html:
 
 def _find_partial_reports(self):
 partial_reports = {}
-for symbol_set in self.symbol_sets_list:
+for symbol_set in self.symbol_sets:
 set_summary = summary(path.join(self.bsp + "-coverage",
 symbol_set))
 set_summary.parse()
@@ -204,7 +204,7 @@ class report_gen_html:
 def add_covoar_src_path(self):
 table_js_path = path.join(self.covoar_src_path, 'table.js')
 covoar_css_path = path.join(self.covoar_src_path, 'covoar.css')
-for symbol_set in self.symbol_sets_list:
+for symbol_set in self.symbol_sets:
 symbol_set_dir = path.join(self.build_dir,
self.bsp + '-coverage', symbol_set)
 html_files = os.listdir(symbol_set_dir)
@@ -264,27 +264,23 @@ class symbol_parser(object):
 for sset in self.ssets:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+return self.ssets
 except:
 raise error.general('Symbol set parsing failed')
 
-def _write_ini(self):
+def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
 try:
-sets = ', '.join(self.symbol_sets.keys())
+sset = symbol_set
 config.add_section('symbol-sets')
-config.set('symbol-sets', 'sets', sets)
-for key in self.symbol_sets.keys():
-config.add_section(key)
-config.set(key, 'libraries', self.symbol_sets[key])
+config.set('symbol-sets', 'sets', sset)
+config.add_section(sset)
+config.set(sset, 'libraries', self.symbol_sets[sset])
 with open(self.symbol_select_file, 'w') as conf:
 config.write(conf)
 except:
 raise error.general('symbol parser write failed')
 
-def run(self):
-self.parse()
-self._write_ini()
-
 class covoar(object):
 '''
 Covoar runner
@@ -371,20 +367,22 @@ class coverage_run(object):
self.symbol_select_path,
self.symbol_set,
build_dir)
-parser.run()
-covoar_runner = covoar(self.test_dir, self.symbol_select_path,
+symbol_sets = parser.parse()
+for sset in symbol_sets:
+parser.write_ini(sset)
+covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace)
-covoar_runner.run('score', self.symbol_select_path)
-self._generate_reports();
+covoar_runner.run(sset, self.symbol_select_path)
+self._generate_reports(symbol_sets);
 self._summarize();
 finally:
 self._cleanup();
 
-def _generate_reports(self):
+def _generate_reports(self, symbol_sets):
 log.notice('Coverage generating reports')
 if self.report_format == 'html':
-report = report_gen_html(self.symbol_sets,
+report = report_gen_html(symbol_sets,
  self.build_dir,
  self.rtdir,
  self.macros['bsp'])
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

On 30 July 2018 at 21:54, Gedare Bloom  wrote:

> On Mon, Jul 30, 2018 at 3:30 AM, Vijay Kumar Banerjee
>  wrote:
> > Invoke covoar multiple times from the script to generate separate
> > reports for each symbol-set.
> > ---
> >  tester/rt/coverage.py | 32 +++-
> >  1 file changed, 15 insertions(+), 17 deletions(-)
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > index 7dd5002..99342e1 100644
> > --- a/tester/rt/coverage.py
> > +++ b/tester/rt/coverage.py
> > @@ -100,7 +100,7 @@ class summary:
> >
> >  class report_gen_html:
> >  def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
> > -self.symbol_sets_list = ['score']
> > +self.symbol_sets_list = p_symbol_sets_list
>
> This is still encoding _list in the names of these variables
>
Sorry about this. Will change it. :)

>
> >  self.build_dir = build_dir
> >  self.partial_reports_files = list(['index.html', 'summary.txt'])
> >  self.number_of_columns = 1
> > @@ -264,27 +264,23 @@ class symbol_parser(object):
> >  for sset in self.ssets:
> >  lib = path.join(self.build_dir, config.get('libraries',
> sset))
> >  self.symbol_sets[sset] = lib.encode('utf-8')
> > +return self.ssets
> >  except:
> >  raise error.general('Symbol set parsing failed')
> >
> > -def _write_ini(self):
> > +def write_ini(self, symbol_set):
> >  config = configparser.ConfigParser()
> >  try:
> > -sets = ', '.join(self.symbol_sets.keys())
> > +sset = symbol_set
> >  config.add_section('symbol-sets')
> > -config.set('symbol-sets', 'sets', sets)
> > -for key in self.symbol_sets.keys():
> > -config.add_section(key)
> > -config.set(key, 'libraries', self.symbol_sets[key])
> > +config.set('symbol-sets', 'sets', sset)
> > +config.add_section(sset)
> > +config.set(sset, 'libraries', self.symbol_sets[sset])
> >  with open(self.symbol_select_file, 'w') as conf:
> >  config.write(conf)
> >  except:
> >  raise error.general('symbol parser write failed')
> >
> > -def run(self):
> > -self.parse()
> > -self._write_ini()
> > -
> >  class covoar(object):
> >  '''
> >  Covoar runner
> > @@ -371,20 +367,22 @@ class coverage_run(object):
> > self.symbol_select_path,
> > self.symbol_set,
> > build_dir)
> > -parser.run()
> > -covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > +symbol_sets = parser.parse()
> > +for sset in symbol_sets:
> > +parser.write_ini(sset)
> > +covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > self.executables,
> self.explanations_txt,
> > self.trace)
> > -covoar_runner.run('score', self.symbol_select_path)
> > -self._generate_reports();
> > +covoar_runner.run(sset, self.symbol_select_path)
> > +self._generate_reports(symbol_sets);
> >  self._summarize();
> >  finally:
> >  self._cleanup();
> >
> > -def _generate_reports(self):
> > +def _generate_reports(self, symbol_sets):
> >  log.notice('Coverage generating reports')
> >  if self.report_format == 'html':
> > -report = report_gen_html(self.symbol_sets,
> > +report = report_gen_html(symbol_sets,
> >   self.build_dir,
> >   self.rtdir,
> >   self.macros['bsp'])
> > --
> > 2.14.4
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Invoke covoar multiple times from the script to generate separate
reports for each symbol-set.
---
 tester/rt/coverage.py | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 7dd5002..99342e1 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -100,7 +100,7 @@ class summary:
 
 class report_gen_html:
 def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
-self.symbol_sets_list = ['score']
+self.symbol_sets_list = p_symbol_sets_list
 self.build_dir = build_dir
 self.partial_reports_files = list(['index.html', 'summary.txt'])
 self.number_of_columns = 1
@@ -264,27 +264,23 @@ class symbol_parser(object):
 for sset in self.ssets:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+return self.ssets
 except:
 raise error.general('Symbol set parsing failed')
 
-def _write_ini(self):
+def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
 try:
-sets = ', '.join(self.symbol_sets.keys())
+sset = symbol_set
 config.add_section('symbol-sets')
-config.set('symbol-sets', 'sets', sets)
-for key in self.symbol_sets.keys():
-config.add_section(key)
-config.set(key, 'libraries', self.symbol_sets[key])
+config.set('symbol-sets', 'sets', sset)
+config.add_section(sset)
+config.set(sset, 'libraries', self.symbol_sets[sset])
 with open(self.symbol_select_file, 'w') as conf:
 config.write(conf)
 except:
 raise error.general('symbol parser write failed')
 
-def run(self):
-self.parse()
-self._write_ini()
-
 class covoar(object):
 '''
 Covoar runner
@@ -371,20 +367,22 @@ class coverage_run(object):
self.symbol_select_path,
self.symbol_set,
build_dir)
-parser.run()
-covoar_runner = covoar(self.test_dir, self.symbol_select_path,
+symbol_sets = parser.parse()
+for sset in symbol_sets:
+parser.write_ini(sset)
+covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace)
-covoar_runner.run('score', self.symbol_select_path)
-self._generate_reports();
+covoar_runner.run(sset, self.symbol_select_path)
+self._generate_reports(symbol_sets);
 self._summarize();
 finally:
 self._cleanup();
 
-def _generate_reports(self):
+def _generate_reports(self, symbol_sets):
 log.notice('Coverage generating reports')
 if self.report_format == 'html':
-report = report_gen_html(self.symbol_sets,
+report = report_gen_html(symbol_sets,
  self.build_dir,
  self.rtdir,
  self.macros['bsp'])
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

On 30 July 2018 at 06:27, Chris Johns  wrote:

> On 26/07/2018 01:40, Vijay Kumar Banerjee wrote:
> > Invoke covoar multiple times from the script to generate separate
> > reports for each symbol-set.
> > ---
> >  tester/rt/coverage.py | 42 --
> >  1 file changed, 20 insertions(+), 22 deletions(-)
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > index 7dd5002..fe92d0a 100644
> > --- a/tester/rt/coverage.py
> > +++ b/tester/rt/coverage.py
> > @@ -100,7 +100,7 @@ class summary:
> >
> >  class report_gen_html:
> >  def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
>
> I am not a fan of adding type info to variable names, for example
> 'p_symbol_sets_list' where a design change may make this a dict. Please use
> something else.
>
Understood. Thanks.

>
> > -self.symbol_sets_list = ['score']
> > +self.symbol_sets_list = p_symbol_sets_list
>
>
> >  self.build_dir = build_dir
> >  self.partial_reports_files = list(['index.html', 'summary.txt'])
> >  self.number_of_columns = 1
> > @@ -250,41 +250,37 @@ class symbol_parser(object):
> >  self.build_dir = build_dir
> >  self.symbol_sets = {}
> >  self.symbol_set = symbol_set
> > -self.ssets = []
> > +self.symbol_set_list = []
>
> Same here and so on in the patch. Also I do not think this last change is
> needed.
>
Understood. I'll remove this last change.

>
> Chris
>
> >
> >  def parse(self):
> >  config = configparser.ConfigParser()
> >  try:
> >  config.read(self.symbol_file)
> >  if self.symbol_set is not None:
> > -self.ssets = self.symbol_set.split(',')
> > +self.symbol_set_list = self.symbol_set.split(',')
> >  else:
> > -self.ssets = config.get('symbol-sets',
> 'sets').split(',')
> > -self.ssets = [sset.encode('utf-8') for sset in
> self.ssets]
> > -for sset in self.ssets:
> > +self.symbol_set_list = config.get('symbol-sets',
> 'sets').split(',')
> > +self.symbol_set_list = [sset.encode('utf-8') for sset
> in self.symbol_set_list]
> > +for sset in self.symbol_set_list:
> >  lib = path.join(self.build_dir, config.get('libraries',
> sset))
> >  self.symbol_sets[sset] = lib.encode('utf-8')
> > +return self.symbol_set_list
> >  except:
> >  raise error.general('Symbol set parsing failed')
> >
> > -def _write_ini(self):
> > +def write_ini(self, symbol_set):
> >  config = configparser.ConfigParser()
> >  try:
> > -sets = ', '.join(self.symbol_sets.keys())
> > +sset = symbol_set
> >  config.add_section('symbol-sets')
> > -config.set('symbol-sets', 'sets', sets)
> > -for key in self.symbol_sets.keys():
> > -config.add_section(key)
> > -config.set(key, 'libraries', self.symbol_sets[key])
> > +config.set('symbol-sets', 'sets', sset)
> > +config.add_section(sset)
> > +config.set(sset, 'libraries', self.symbol_sets[sset])
> >  with open(self.symbol_select_file, 'w') as conf:
> >  config.write(conf)
> >  except:
> >  raise error.general('symbol parser write failed')
> >
> > -def run(self):
> > -self.parse()
> > -self._write_ini()
> > -
> >  class covoar(object):
> >  '''
> >  Covoar runner
> > @@ -371,20 +367,22 @@ class coverage_run(object):
> > self.symbol_select_path,
> > self.symbol_set,
> > build_dir)
> > -parser.run()
> > -covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > +symbol_set_list = parser.parse()
> > +for sset in symbol_set_list:
> > +parser.write_ini(sset)
> > +covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > self.executables,
> self.explanations_txt,
> > self.trace)
> > -covoar_runner.run('score', self.symbol_s

Re: [PATCH v2 1/2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

ping. :)

On 25 July 2018 at 21:10, Vijay Kumar Banerjee 
wrote:

> Invoke covoar multiple times from the script to generate separate
> reports for each symbol-set.
> ---
>  tester/rt/coverage.py | 42 --
>  1 file changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> index 7dd5002..fe92d0a 100644
> --- a/tester/rt/coverage.py
> +++ b/tester/rt/coverage.py
> @@ -100,7 +100,7 @@ class summary:
>
>  class report_gen_html:
>  def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
> -self.symbol_sets_list = ['score']
> +self.symbol_sets_list = p_symbol_sets_list
>  self.build_dir = build_dir
>  self.partial_reports_files = list(['index.html', 'summary.txt'])
>  self.number_of_columns = 1
> @@ -250,41 +250,37 @@ class symbol_parser(object):
>  self.build_dir = build_dir
>  self.symbol_sets = {}
>  self.symbol_set = symbol_set
> -self.ssets = []
> +self.symbol_set_list = []
>
>  def parse(self):
>  config = configparser.ConfigParser()
>  try:
>  config.read(self.symbol_file)
>  if self.symbol_set is not None:
> -self.ssets = self.symbol_set.split(',')
> +self.symbol_set_list = self.symbol_set.split(',')
>  else:
> -self.ssets = config.get('symbol-sets', 'sets').split(',')
> -self.ssets = [sset.encode('utf-8') for sset in self.ssets]
> -for sset in self.ssets:
> +self.symbol_set_list = config.get('symbol-sets',
> 'sets').split(',')
> +self.symbol_set_list = [sset.encode('utf-8') for sset in
> self.symbol_set_list]
> +for sset in self.symbol_set_list:
>  lib = path.join(self.build_dir, config.get('libraries',
> sset))
>  self.symbol_sets[sset] = lib.encode('utf-8')
> +return self.symbol_set_list
>  except:
>  raise error.general('Symbol set parsing failed')
>
> -def _write_ini(self):
> +def write_ini(self, symbol_set):
>  config = configparser.ConfigParser()
>  try:
> -sets = ', '.join(self.symbol_sets.keys())
> +sset = symbol_set
>  config.add_section('symbol-sets')
> -config.set('symbol-sets', 'sets', sets)
> -for key in self.symbol_sets.keys():
> -config.add_section(key)
> -config.set(key, 'libraries', self.symbol_sets[key])
> +config.set('symbol-sets', 'sets', sset)
> +config.add_section(sset)
> +config.set(sset, 'libraries', self.symbol_sets[sset])
>  with open(self.symbol_select_file, 'w') as conf:
>  config.write(conf)
>  except:
>  raise error.general('symbol parser write failed')
>
> -def run(self):
> -self.parse()
> -self._write_ini()
> -
>  class covoar(object):
>  '''
>  Covoar runner
> @@ -371,20 +367,22 @@ class coverage_run(object):
> self.symbol_select_path,
> self.symbol_set,
> build_dir)
> -parser.run()
> -covoar_runner = covoar(self.test_dir, self.symbol_select_path,
> +symbol_set_list = parser.parse()
> +for sset in symbol_set_list:
> +parser.write_ini(sset)
> +covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> self.executables,
> self.explanations_txt,
> self.trace)
> -covoar_runner.run('score', self.symbol_select_path)
> -self._generate_reports();
> +covoar_runner.run(sset, self.symbol_select_path)
> +self._generate_reports(symbol_set_list);
>  self._summarize();
>  finally:
>  self._cleanup();
>
> -def _generate_reports(self):
> +def _generate_reports(self, symbol_sets):
>  log.notice('Coverage generating reports')
>  if self.report_format == 'html':
> -report = report_gen_html(self.symbol_sets,
> +report = report_gen_html(symbol_sets,
>   self.build_dir,
>   self.rtdir,
>   self.macros['bsp'])
> --
> 2.14.4
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

On Thu, Jul 26, 2018, 11:29 PM Cillian O'Donnell 
wrote:

>
>
> On Thu, 26 Jul 2018, 18:51 Vijay Kumar Banerjee, 
> wrote:
>
>>
>>
>> On Thu, Jul 26, 2018, 10:34 PM Cillian O'Donnell 
>> wrote:
>>
>>> Kryzstof is the original author, so his name should probably stick. You
>>> could add lines for
>>>
>>> Reviewed by: Vijay on date: ...
>>>
>>> I think that's standard enough
>>>
>>> All the best,
>>>
>>> Cillian
>>>
>> Thanks for the reply and for all the help
>> throughout the summer. It was a great
>> experience !!
>>
>
> I'm glad you enjoyed it! Sorry I was so quiet over gcov phase, I just
> don't much about it and couldn't seem to catch up.
>
That's alright. :)
Would love to work with you again in the
future.

>
> It's a great achievement to make through gsoc. Many are called, but few
> are chosen... and even fewer can finish..:) Well done!
>
Thanks!
This is an awesome community, would
continue to be an active part of it. :)

>
>>>> On Thu, 26 Jul 2018, 17:22 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have a question which I forgot to ask before.
>>>> Should the coverage.py and symbol-sets.ini files have mine and/or
>>>> Cillian's name
>>>> included in the copyright notice?
>>>>
>>>> --vijayk
>>>> On 26 July 2018 at 13:09, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> I have added all the libs in cpukit and commented them out.
>>>>> Please have a look at the attached file.
>>>>>
>>>>> On 26 July 2018 at 04:50, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 25, 2018 at 10:41 AM, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> ---
>>>>>>>  tester/rtems/testing/coverage/symbol-sets.ini | 11 ---
>>>>>>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> index a2ec7bc..3900f14 100644
>>>>>>> --- a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> @@ -29,8 +29,13 @@
>>>>>>>  #
>>>>>>>
>>>>>>>  [symbol-sets]
>>>>>>> -sets = score,rtems
>>>>>>> +sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
>>>>>>>
>>>>>>>  [libraries]
>>>>>>> -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>>>> -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>>>> +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>>>> +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>>>> +libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
>>>>>>> +libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
>>>>>>> +libcsupport   = @BUILD-TARGET@/c/@BSP@
>>>>>>> /cpukit/libcsupport/libcsupport.a
>>>>>>> +libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
>>>>>>> +libnetworking = @BUILD-TARGET@/c/@BSP@
>>>>>>> /cpukit/libnetworking/libnetworking.a
>>>>>>>
>>>>>>
>>>>>> To be at parity with the old reports but reported on finer
>>>>>> granularity,
>>>>>> follow the list at
>>>>>>
>>>>>>
>>>>>> https://git.rtems.org/rtems-testing/tree/rtems-coverage/do_coverage#n507
>>>>>>
>>>>>> and check what is not listed there that is in cpukit now.  For
>>>>>> example, jffs2
>>>>>> isn't listed in the above. But the things consciously skipped have a
>>>>>> good
>>>>>> reason. Add a list of the ones not included. It may make sense to
>>>>>> have something like this for the ones deliberately skipped:
>>>>>>
>>>>>> # librpc = @libXXX.a
>>>>>>
>>>>>> It will make auditing what's in the cpukit versus the ini file easier.
>>>>>> That's why my old script has them in order and commented out the
>>>>>> ones we were not ready to do or never would.
>>>>>>
>>>>>> But for sure, add posix, sapi, libdl, individual filesystem, and catch
>>>>>> the libmisc subdirectories listed in the old script for inclusion.
>>>>>> for new
>>>>>> libmisc content, we can make a decision.
>>>>>>
>>>>>> Don't include libnetworking. As a general rule, we don't do coverage
>>>>>> testing
>>>>>> on networking or any  (complex) third party software.
>>>>>>
>>>>>> I don't think dtc will get coverage either.
>>>>>>
>>>>>> That should get us closer. I expect you will find some libraries
>>>>>> to ask questions on. :)
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>>
>>>>>>> --
>>>>>>> 2.14.4
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

On Thu, Jul 26, 2018, 10:34 PM Cillian O'Donnell 
wrote:

> Kryzstof is the original author, so his name should probably stick. You
> could add lines for
>
> Reviewed by: Vijay on date: ...
>
> I think that's standard enough
>
> All the best,
>
> Cillian
>
Thanks for the reply and for all the help
throughout the summer. It was a great
experience !!

>
>> On Thu, 26 Jul 2018, 17:22 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I have a question which I forgot to ask before.
>> Should the coverage.py and symbol-sets.ini files have mine and/or
>> Cillian's name
>> included in the copyright notice?
>>
>> --vijayk
>> On 26 July 2018 at 13:09, Vijay Kumar Banerjee 
>> wrote:
>>
>>> I have added all the libs in cpukit and commented them out.
>>> Please have a look at the attached file.
>>>
>>> On 26 July 2018 at 04:50, Joel Sherrill  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 25, 2018 at 10:41 AM, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> ---
>>>>>  tester/rtems/testing/coverage/symbol-sets.ini | 11 ---
>>>>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>> index a2ec7bc..3900f14 100644
>>>>> --- a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>> @@ -29,8 +29,13 @@
>>>>>  #
>>>>>
>>>>>  [symbol-sets]
>>>>> -sets = score,rtems
>>>>> +sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
>>>>>
>>>>>  [libraries]
>>>>> -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>> -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>> +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>> +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>> +libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
>>>>> +libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
>>>>> +libcsupport   = @BUILD-TARGET@/c/@BSP@
>>>>> /cpukit/libcsupport/libcsupport.a
>>>>> +libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
>>>>> +libnetworking = @BUILD-TARGET@/c/@BSP@
>>>>> /cpukit/libnetworking/libnetworking.a
>>>>>
>>>>
>>>> To be at parity with the old reports but reported on finer granularity,
>>>> follow the list at
>>>>
>>>> https://git.rtems.org/rtems-testing/tree/rtems-coverage/do_coverage#n507
>>>>
>>>> and check what is not listed there that is in cpukit now.  For example,
>>>> jffs2
>>>> isn't listed in the above. But the things consciously skipped have a
>>>> good
>>>> reason. Add a list of the ones not included. It may make sense to
>>>> have something like this for the ones deliberately skipped:
>>>>
>>>> # librpc = @libXXX.a
>>>>
>>>> It will make auditing what's in the cpukit versus the ini file easier.
>>>> That's why my old script has them in order and commented out the
>>>> ones we were not ready to do or never would.
>>>>
>>>> But for sure, add posix, sapi, libdl, individual filesystem, and catch
>>>> the libmisc subdirectories listed in the old script for inclusion. for
>>>> new
>>>> libmisc content, we can make a decision.
>>>>
>>>> Don't include libnetworking. As a general rule, we don't do coverage
>>>> testing
>>>> on networking or any  (complex) third party software.
>>>>
>>>> I don't think dtc will get coverage either.
>>>>
>>>> That should get us closer. I expect you will find some libraries
>>>> to ask questions on. :)
>>>>
>>>> --joel
>>>>
>>>>
>>>>> --
>>>>> 2.14.4
>>>>>
>>>>>
>>>>
>>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

Hello,

I have a question which I forgot to ask before.
Should the coverage.py and symbol-sets.ini files have mine and/or Cillian's
name
included in the copyright notice?

--vijayk
On 26 July 2018 at 13:09, Vijay Kumar Banerjee 
wrote:

> I have added all the libs in cpukit and commented them out.
> Please have a look at the attached file.
>
> On 26 July 2018 at 04:50, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Jul 25, 2018 at 10:41 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> ---
>>>  tester/rtems/testing/coverage/symbol-sets.ini | 11 ---
>>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>> index a2ec7bc..3900f14 100644
>>> --- a/tester/rtems/testing/coverage/symbol-sets.ini
>>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>> @@ -29,8 +29,13 @@
>>>  #
>>>
>>>  [symbol-sets]
>>> -sets = score,rtems
>>> +sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
>>>
>>>  [libraries]
>>> -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>> -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>> +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>> +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>> +libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
>>> +libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
>>> +libcsupport   = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a
>>> +libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
>>> +libnetworking = @BUILD-TARGET@/c/@BSP@/cpukit/
>>> libnetworking/libnetworking.a
>>>
>>
>> To be at parity with the old reports but reported on finer granularity,
>> follow the list at
>>
>> https://git.rtems.org/rtems-testing/tree/rtems-coverage/do_coverage#n507
>>
>> and check what is not listed there that is in cpukit now.  For example,
>> jffs2
>> isn't listed in the above. But the things consciously skipped have a good
>> reason. Add a list of the ones not included. It may make sense to
>> have something like this for the ones deliberately skipped:
>>
>> # librpc = @libXXX.a
>>
>> It will make auditing what's in the cpukit versus the ini file easier.
>> That's why my old script has them in order and commented out the
>> ones we were not ready to do or never would.
>>
>> But for sure, add posix, sapi, libdl, individual filesystem, and catch
>> the libmisc subdirectories listed in the old script for inclusion. for new
>> libmisc content, we can make a decision.
>>
>> Don't include libnetworking. As a general rule, we don't do coverage
>> testing
>> on networking or any  (complex) third party software.
>>
>> I don't think dtc will get coverage either.
>>
>> That should get us closer. I expect you will find some libraries
>> to ask questions on. :)
>>
>> --joel
>>
>>
>>> --
>>> 2.14.4
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

I have added all the libs in cpukit and commented them out.
Please have a look at the attached file.

On 26 July 2018 at 04:50, Joel Sherrill  wrote:

>
>
> On Wed, Jul 25, 2018 at 10:41 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> ---
>>  tester/rtems/testing/coverage/symbol-sets.ini | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>> b/tester/rtems/testing/coverage/symbol-sets.ini
>> index a2ec7bc..3900f14 100644
>> --- a/tester/rtems/testing/coverage/symbol-sets.ini
>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>> @@ -29,8 +29,13 @@
>>  #
>>
>>  [symbol-sets]
>> -sets = score,rtems
>> +sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
>>
>>  [libraries]
>> -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>> -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>> +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>> +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>> +libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
>> +libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
>> +libcsupport   = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a
>> +libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
>> +libnetworking = @BUILD-TARGET@/c/@BSP@/cpukit/
>> libnetworking/libnetworking.a
>>
>
> To be at parity with the old reports but reported on finer granularity,
> follow the list at
>
> https://git.rtems.org/rtems-testing/tree/rtems-coverage/do_coverage#n507
>
> and check what is not listed there that is in cpukit now.  For example,
> jffs2
> isn't listed in the above. But the things consciously skipped have a good
> reason. Add a list of the ones not included. It may make sense to
> have something like this for the ones deliberately skipped:
>
> # librpc = @libXXX.a
>
> It will make auditing what's in the cpukit versus the ini file easier.
> That's why my old script has them in order and commented out the
> ones we were not ready to do or never would.
>
> But for sure, add posix, sapi, libdl, individual filesystem, and catch
> the libmisc subdirectories listed in the old script for inclusion. for new
> libmisc content, we can make a decision.
>
> Don't include libnetworking. As a general rule, we don't do coverage
> testing
> on networking or any  (complex) third party software.
>
> I don't think dtc will get coverage either.
>
> That should get us closer. I expect you will find some libraries
> to ask questions on. :)
>
> --joel
>
>
>> --
>> 2.14.4
>>
>>
>


symbol-sets.ini
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

[Vijay Kumar Banerjee]

---
 tester/rtems/testing/coverage/symbol-sets.ini | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
b/tester/rtems/testing/coverage/symbol-sets.ini
index a2ec7bc..3900f14 100644
--- a/tester/rtems/testing/coverage/symbol-sets.ini
+++ b/tester/rtems/testing/coverage/symbol-sets.ini
@@ -29,8 +29,13 @@
 #
 
 [symbol-sets]
-sets = score,rtems
+sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
 
 [libraries]
-score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
-rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
+rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
+libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
+libcsupport   = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a
+libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
+libnetworking = @BUILD-TARGET@/c/@BSP@/cpukit/libnetworking/libnetworking.a
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 1/2] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Invoke covoar multiple times from the script to generate separate
reports for each symbol-set.
---
 tester/rt/coverage.py | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 7dd5002..fe92d0a 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -100,7 +100,7 @@ class summary:
 
 class report_gen_html:
 def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
-self.symbol_sets_list = ['score']
+self.symbol_sets_list = p_symbol_sets_list
 self.build_dir = build_dir
 self.partial_reports_files = list(['index.html', 'summary.txt'])
 self.number_of_columns = 1
@@ -250,41 +250,37 @@ class symbol_parser(object):
 self.build_dir = build_dir
 self.symbol_sets = {}
 self.symbol_set = symbol_set
-self.ssets = []
+self.symbol_set_list = []
 
 def parse(self):
 config = configparser.ConfigParser()
 try:
 config.read(self.symbol_file)
 if self.symbol_set is not None:
-self.ssets = self.symbol_set.split(',')
+self.symbol_set_list = self.symbol_set.split(',')
 else:
-self.ssets = config.get('symbol-sets', 'sets').split(',')
-self.ssets = [sset.encode('utf-8') for sset in self.ssets]
-for sset in self.ssets:
+self.symbol_set_list = config.get('symbol-sets', 
'sets').split(',')
+self.symbol_set_list = [sset.encode('utf-8') for sset in 
self.symbol_set_list]
+for sset in self.symbol_set_list:
 lib = path.join(self.build_dir, config.get('libraries', sset))
 self.symbol_sets[sset] = lib.encode('utf-8')
+return self.symbol_set_list 
 except:
 raise error.general('Symbol set parsing failed')
 
-def _write_ini(self):
+def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
 try:
-sets = ', '.join(self.symbol_sets.keys())
+sset = symbol_set
 config.add_section('symbol-sets')
-config.set('symbol-sets', 'sets', sets)
-for key in self.symbol_sets.keys():
-config.add_section(key)
-config.set(key, 'libraries', self.symbol_sets[key])
+config.set('symbol-sets', 'sets', sset)
+config.add_section(sset)
+config.set(sset, 'libraries', self.symbol_sets[sset])
 with open(self.symbol_select_file, 'w') as conf:
 config.write(conf)
 except:
 raise error.general('symbol parser write failed')
 
-def run(self):
-self.parse()
-self._write_ini()
-
 class covoar(object):
 '''
 Covoar runner
@@ -371,20 +367,22 @@ class coverage_run(object):
self.symbol_select_path,
self.symbol_set,
build_dir)
-parser.run()
-covoar_runner = covoar(self.test_dir, self.symbol_select_path,
+symbol_set_list = parser.parse()
+for sset in symbol_set_list:
+parser.write_ini(sset)
+covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace)
-covoar_runner.run('score', self.symbol_select_path)
-self._generate_reports();
+covoar_runner.run(sset, self.symbol_select_path)
+self._generate_reports(symbol_set_list);
 self._summarize();
 finally:
 self._cleanup();
 
-def _generate_reports(self):
+def _generate_reports(self, symbol_sets):
 log.notice('Coverage generating reports')
 if self.report_format == 'html':
-report = report_gen_html(self.symbol_sets,
+report = report_gen_html(symbol_sets,
  self.build_dir,
  self.rtdir,
  self.macros['bsp'])
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

On 25 July 2018 at 20:06, Gedare Bloom  wrote:

> On Tue, Jul 24, 2018 at 10:37 PM, Vijay Kumar Banerjee
>  wrote:
> > Invoke covoar multiple times from the script to generate separate
> > reports for each symbol-set.
> > ---
> >  tester/rt/coverage.py | 32
> +--
> >  tester/rtems/testing/coverage/symbol-sets.ini | 11 ++---
> >  2 files changed, 23 insertions(+), 20 deletions(-)
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > index 7dd5002..e2f4dca 100644
> > --- a/tester/rt/coverage.py
> > +++ b/tester/rt/coverage.py
> > @@ -100,7 +100,7 @@ class summary:
> >
> >  class report_gen_html:
> >  def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
> > -self.symbol_sets_list = ['score']
> > +self.symbol_sets_list = p_symbol_sets_list
> >  self.build_dir = build_dir
> >  self.partial_reports_files = list(['index.html', 'summary.txt'])
> >  self.number_of_columns = 1
> > @@ -267,24 +267,19 @@ class symbol_parser(object):
> >  except:
> >  raise error.general('Symbol set parsing failed')
> >
> > -def _write_ini(self):
> > +def write_ini(self, symbol_set):
> >  config = configparser.ConfigParser()
> >  try:
> > -sets = ', '.join(self.symbol_sets.keys())
> > +sset = symbol_set
> >  config.add_section('symbol-sets')
> > -config.set('symbol-sets', 'sets', sets)
> > -for key in self.symbol_sets.keys():
> > -config.add_section(key)
> > -config.set(key, 'libraries', self.symbol_sets[key])
> > +config.set('symbol-sets', 'sets', sset)
> > +config.add_section(sset)
> > +config.set(sset, 'libraries', self.symbol_sets[sset])
> >  with open(self.symbol_select_file, 'w') as conf:
> >  config.write(conf)
> >  except:
> >  raise error.general('symbol parser write failed')
> >
> > -def run(self):
> > -self.parse()
> > -self._write_ini()
> > -
> >  class covoar(object):
> >  '''
> >  Covoar runner
> > @@ -371,20 +366,23 @@ class coverage_run(object):
> > self.symbol_select_path,
> > self.symbol_set,
> > build_dir)
> > -parser.run()
> > -covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > +parser.parse()
> > +ssets = parser.symbol_sets.keys()
> I don't like this two-line combination. It requires knowledge about
> the internal workings of the parser class. Maybe it makes sense to
> have parser.parse() returns the symbol_sets directly?

Understood, thanks.

>


> Also, I prefer if you kept symbol_sets as a name, but you can use the
> sset for the shortened single "symbol_set". the intermixing of
> symbol_sets, sset, and ssets is confusing to me.
>
> Will change it to symbol_sets.

>
> > +for sset in ssets:
> > +parser.write_ini(sset)
> > +covoar_runner = covoar(self.test_dir,
> self.symbol_select_path,
> > self.executables,
> self.explanations_txt,
> > self.trace)
> > -covoar_runner.run('score', self.symbol_select_path)
> > -self._generate_reports();
> > +covoar_runner.run(sset, self.symbol_select_path)
> > +self._generate_reports(ssets);
> You could keep the symbol_sets as a class variable if you want to.
> either way is probably fine...
>
> >  self._summarize();
> >  finally:
> >  self._cleanup();
> >
> > -def _generate_reports(self):
> > +def _generate_reports(self, symbol_sets):
> >  log.notice('Coverage generating reports')
> >  if self.report_format == 'html':
> > -report = report_gen_html(self.symbol_sets,
> > +report = report_gen_html(symbol_sets,
> >   self.build_dir,
> >   self.rtdir,
> >   self.macros['bsp'])
> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
> b/tester/rtems/testing/coverage/symbol-sets.ini
> > index a2ec7bc..3900f14 100644
> > --- a/tester/rtems

[PATCH] Coverage: Add support to generate separate reports for each symbol-set

[Vijay Kumar Banerjee]

Invoke covoar multiple times from the script to generate separate
reports for each symbol-set.
---
 tester/rt/coverage.py | 32 +--
 tester/rtems/testing/coverage/symbol-sets.ini | 11 ++---
 2 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 7dd5002..e2f4dca 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -100,7 +100,7 @@ class summary:
 
 class report_gen_html:
 def __init__(self, p_symbol_sets_list, build_dir, rtdir, bsp):
-self.symbol_sets_list = ['score']
+self.symbol_sets_list = p_symbol_sets_list
 self.build_dir = build_dir
 self.partial_reports_files = list(['index.html', 'summary.txt'])
 self.number_of_columns = 1
@@ -267,24 +267,19 @@ class symbol_parser(object):
 except:
 raise error.general('Symbol set parsing failed')
 
-def _write_ini(self):
+def write_ini(self, symbol_set):
 config = configparser.ConfigParser()
 try:
-sets = ', '.join(self.symbol_sets.keys())
+sset = symbol_set
 config.add_section('symbol-sets')
-config.set('symbol-sets', 'sets', sets)
-for key in self.symbol_sets.keys():
-config.add_section(key)
-config.set(key, 'libraries', self.symbol_sets[key])
+config.set('symbol-sets', 'sets', sset)
+config.add_section(sset)
+config.set(sset, 'libraries', self.symbol_sets[sset])
 with open(self.symbol_select_file, 'w') as conf:
 config.write(conf)
 except:
 raise error.general('symbol parser write failed')
 
-def run(self):
-self.parse()
-self._write_ini()
-
 class covoar(object):
 '''
 Covoar runner
@@ -371,20 +366,23 @@ class coverage_run(object):
self.symbol_select_path,
self.symbol_set,
build_dir)
-parser.run()
-covoar_runner = covoar(self.test_dir, self.symbol_select_path,
+parser.parse()
+ssets = parser.symbol_sets.keys()
+for sset in ssets:
+parser.write_ini(sset)
+covoar_runner = covoar(self.test_dir, self.symbol_select_path,
self.executables, self.explanations_txt,
self.trace)
-covoar_runner.run('score', self.symbol_select_path)
-self._generate_reports();
+covoar_runner.run(sset, self.symbol_select_path)
+self._generate_reports(ssets);
 self._summarize();
 finally:
 self._cleanup();
 
-def _generate_reports(self):
+def _generate_reports(self, symbol_sets):
 log.notice('Coverage generating reports')
 if self.report_format == 'html':
-report = report_gen_html(self.symbol_sets,
+report = report_gen_html(symbol_sets,
  self.build_dir,
  self.rtdir,
  self.macros['bsp'])
diff --git a/tester/rtems/testing/coverage/symbol-sets.ini 
b/tester/rtems/testing/coverage/symbol-sets.ini
index a2ec7bc..3900f14 100644
--- a/tester/rtems/testing/coverage/symbol-sets.ini
+++ b/tester/rtems/testing/coverage/symbol-sets.ini
@@ -29,8 +29,13 @@
 #
 
 [symbol-sets]
-sets = score,rtems
+sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
 
 [libraries]
-score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
-rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
+rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
+libblock  = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
+libcrypt  = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
+libcsupport   = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a
+libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
+libnetworking = @BUILD-TARGET@/c/@BSP@/cpukit/libnetworking/libnetworking.a
-- 
2.14.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: coverage : error when running --coverage with rtems-test for whole testsuites

[Vijay Kumar Banerjee]

On 21 July 2018 at 03:49, Vijay Kumar Banerjee 
wrote:

> On Fri, Jul 20, 2018, 10:08 PM Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom  wrote:
>>
>>> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee
>>>  wrote:
>>> > Hello,
>>> >
>>> > I used the following command
>>> >
>>> > 
>>> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \
>>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
>>> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
>>> > /home/lunatic/development/rtems/kernel/leon3/sparc-
>>> rtems5/c/leon3/testsuites
>>> > --debug-trace=cov
>>> > 
>>> >
>>> > and I'm getting the following error
>>> >
>>> > ===
>>> > error: coverage: covoar failure:: -9
>>> > ===
>>> >
>>>
>>> What does error code -9 mean from covoar?
>>>
>>> Does it make any progress at all?
>>>
>>
>> Can you capture the command line used to invoke covoar and
>> run it in gdb? That's an odd error message. covoar is usually
>> good at printing something useful. It was written to be paranoid.
>>
> yes I'm trying to run it in gdb, the laptop
> freezes for a long time and I have to
> restart it, I'll give it more time tommorow
> and let it take as much time as it wants
>
> It runs fine for samples/ so we're searching
> for a small test case where it trips, so
> I'll run it separately for each set of tests,
> like benchmarks/ , fstests/ ...
>
>
>>
>>>
>>> > This, however, runs fine for samples/
>>> >
>>>
>>> does this command work for you without using the cov options?
>>>
>>> > I think this will probably be on hold as Chris seems to be
>>> > on a break, meanwhile, I want to do a wrapup work on
>>> > the non-gcov coverage reports, I seek suggestions/advice
>>> > for the same.
>>> >
>>> > The current state is that the coverage reports can be generated
>>> > for one symbol-set only, There's a ticket for the support of
>>> > generating separate reports of multiple sets from covoar.
>>> >
>>> > https://devel.rtems.org/ticket/3441
>>
>>
>> I thought originally that the Python would invoke covoar multiple
>> times. It was slower but that was how it was originally designed.
>> Is there no support in the Python for doing this?
>>
> I was building it in a way that the script invokes
> covoar multiple times, but Chris' modifications
> to covoar added support for reading multiple symbol-sets
> after which I changed the coverage script.
>
> If we're planning to have this support in
> the python script untill covoar is updated,
> then I can add it.
>
I managed to get this work, please see the attached image.
If we're looking to get this support in the script, I'll send the patch. :)

>
>
>>
>>>
>>> >
>>> > Please let me know of any suggestions including suggestions
>>> > regarding documentation as Coverage needs more
>>> > documentation.
>>> >
>>>
>>> What is the existing documentation for coverage?
>>>
>>
>> That's an important part of reproducability.
>>
>>
>>>
>>> > Thanks
>>> > -- vijay
>>> >
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: coverage : error when running --coverage with rtems-test for whole testsuites

[Vijay Kumar Banerjee]

On Fri, Jul 20, 2018, 10:08 PM Joel Sherrill  wrote:

>
>
> On Fri, Jul 20, 2018 at 9:14 AM, Gedare Bloom  wrote:
>
>> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee
>>  wrote:
>> > Hello,
>> >
>> > I used the following command
>> >
>> > 
>> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \
>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
>> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
>> >
>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites
>> > --debug-trace=cov
>> > 
>> >
>> > and I'm getting the following error
>> >
>> > ===
>> > error: coverage: covoar failure:: -9
>> > ===
>> >
>>
>> What does error code -9 mean from covoar?
>>
>> Does it make any progress at all?
>>
>
> Can you capture the command line used to invoke covoar and
> run it in gdb? That's an odd error message. covoar is usually
> good at printing something useful. It was written to be paranoid.
>
yes I'm trying to run it in gdb, the laptop
freezes for a long time and I have to
restart it, I'll give it more time tommorow
and let it take as much time as it wants

It runs fine for samples/ so we're searching
for a small test case where it trips, so
I'll run it separately for each set of tests,
like benchmarks/ , fstests/ ...


>
>>
>> > This, however, runs fine for samples/
>> >
>>
>> does this command work for you without using the cov options?
>>
>> > I think this will probably be on hold as Chris seems to be
>> > on a break, meanwhile, I want to do a wrapup work on
>> > the non-gcov coverage reports, I seek suggestions/advice
>> > for the same.
>> >
>> > The current state is that the coverage reports can be generated
>> > for one symbol-set only, There's a ticket for the support of
>> > generating separate reports of multiple sets from covoar.
>> >
>> > https://devel.rtems.org/ticket/3441
>
>
> I thought originally that the Python would invoke covoar multiple
> times. It was slower but that was how it was originally designed.
> Is there no support in the Python for doing this?
>
I was building it in a way that the script invokes
covoar multiple times, but Chris' modifications
to covoar added support for reading multiple symbol-sets
after which I changed the coverage script.

If we're planning to have this support in
the python script untill covoar is updated,
then I can add it.


>
>>
>> >
>> > Please let me know of any suggestions including suggestions
>> > regarding documentation as Coverage needs more
>> > documentation.
>> >
>>
>> What is the existing documentation for coverage?
>>
>
> That's an important part of reproducability.
>
>
>>
>> > Thanks
>> > -- vijay
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: coverage : error when running --coverage with rtems-test for whole testsuites

[Vijay Kumar Banerjee]

On Fri, Jul 20, 2018, 9:19 PM Gedare Bloom  wrote:

> On Fri, Jul 20, 2018 at 11:43 AM, Vijay Kumar Banerjee
>  wrote:
> > On 20 July 2018 at 19:44, Gedare Bloom  wrote:
> >>
> >> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee
> >>  wrote:
> >> > Hello,
> >> >
> >> > I used the following command
> >> >
> >> > 
> >> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \
> >> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
> >> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
> >> >
> >> >
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites
> >> > --debug-trace=cov
> >> > 
> >> >
> >> > and I'm getting the following error
> >> >
> >> > ===
> >> > error: coverage: covoar failure:: -9
> >> > ===
> >> >
> >>
> >> What does error code -9 mean from covoar?
> >>
> > I don't know what does code -9 mean.
> > The error is coming from here
> >
> https://github.com/RTEMS/rtems-tools/blob/master/tester/rt/coverage.py#L329
> >
>
> I should have said, "Can you figure out what error code -9 means?"
> You'll have to trace back to find where it originates.
>
I am looking into it.

> > I will run coverage for testsuites/ again and upload the log file here.
> >>
> >> Does it make any progress at all?
> >>
> > The tests are running but coverage doesn't progress at all.
> >>
> >> > This, however, runs fine for samples/
> >> >
> >>
> >> does this command work for you without using the cov options?
> >>
> > yes
> >>
> >> > I think this will probably be on hold as Chris seems to be
> >> > on a break, meanwhile, I want to do a wrapup work on
> >> > the non-gcov coverage reports, I seek suggestions/advice
> >> > for the same.
> >> >
> >> > The current state is that the coverage reports can be generated
> >> > for one symbol-set only, There's a ticket for the support of
> >> > generating separate reports of multiple sets from covoar.
> >> >
> >> > https://devel.rtems.org/ticket/3441
> >> >
> >> > Please let me know of any suggestions including suggestions
> >> > regarding documentation as Coverage needs more
> >> > documentation.
> >> >
> >>
> >> What is the existing documentation for coverage?
> >>
> > I found these links
> >
> > https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis
> > https://devel.rtems.org/wiki/Developer/Coverage/Theory
> > https://devel.rtems.org/wiki/Developer/Coverage/Analysis
> >
>
> We need to capture this stuff in a proper manual. At least it could
> start as a chapter in the user manual, maybe? @Joel ideas?
>
> >> > Thanks
> >> > -- vijay
> >> >
> >> > ___
> >> > devel mailing list
> >> > devel@rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: coverage : error when running --coverage with rtems-test for whole testsuites

[Vijay Kumar Banerjee]

On 20 July 2018 at 19:44, Gedare Bloom  wrote:

> On Thu, Jul 19, 2018 at 6:29 PM, Vijay Kumar Banerjee
>  wrote:
> > Hello,
> >
> > I used the following command
> >
> > 
> > $HOME/development/rtems/test/rtems-tools/tester/rtems-test \
> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
> > --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
> > /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites
> > --debug-trace=cov
> > 
> >
> > and I'm getting the following error
> >
> > ===
> > error: coverage: covoar failure:: -9
> > ===
> >
>
> What does error code -9 mean from covoar?
>
> I don't know what does code -9 mean.
The error is coming from here
https://github.com/RTEMS/rtems-tools/blob/master/tester/rt/coverage.py#L329

I will run coverage for testsuites/ again and upload the log file here.

> Does it make any progress at all?
>
> The tests are running but coverage doesn't progress at all.

> > This, however, runs fine for samples/
> >
>
> does this command work for you without using the cov options?
>
> yes

> > I think this will probably be on hold as Chris seems to be
> > on a break, meanwhile, I want to do a wrapup work on
> > the non-gcov coverage reports, I seek suggestions/advice
> > for the same.
> >
> > The current state is that the coverage reports can be generated
> > for one symbol-set only, There's a ticket for the support of
> > generating separate reports of multiple sets from covoar.
> >
> > https://devel.rtems.org/ticket/3441
> >
> > Please let me know of any suggestions including suggestions
> > regarding documentation as Coverage needs more
> > documentation.
> >
>
> What is the existing documentation for coverage?
>
> I found these links

https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis
https://devel.rtems.org/wiki/Developer/Coverage/Theory
https://devel.rtems.org/wiki/Developer/Coverage/Analysis

> Thanks
> > -- vijay
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

coverage : error when running --coverage with rtems-test for whole testsuites

[Vijay Kumar Banerjee]

Hello,

I used the following command


$HOME/development/rtems/test/rtems-tools/tester/rtems-test \
--rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
--no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites
--debug-trace=cov


and I'm getting the following error

===
error: coverage: covoar failure:: -9
===

This, however, runs fine for samples/

I think this will probably be on hold as Chris seems to be
on a break, meanwhile, I want to do a wrapup work on
the non-gcov coverage reports, I seek suggestions/advice
for the same.

The current state is that the coverage reports can be generated
for one symbol-set only, There's a ticket for the support of
generating separate reports of multiple sets from covoar.

https://devel.rtems.org/ticket/3441

Please let me know of any suggestions including suggestions
regarding documentation as Coverage needs more
documentation.

Thanks
-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

Hello,

I have made the changes and also got the confusion with
structure of gcno, cleared to some extent after some
careful reading and experiments.

I'm attaching the txt file generated. So far it is complete up to
function record, next is the basic block records. I will start with
the block records after finalizing the wrapup of the non-gcov
coverage reports to make sure that everything works properly there.

-- vijay

On 18 July 2018 at 17:17, Vijay Kumar Banerjee 
wrote:

> On 18 July 2018 at 02:30, Joel Sherrill  wrote:
>
>> This definitely looks like the right direction. If we don't understand
>> the file formats, we will never be able to process and correlate them.
>>
>> Please put 0x in front of hex numbers. It does help.
>>
>> Can you explain the fields in gcno_dump.txt? The Version field
>> looks like hex for R37A which doesn't make sense to me. Reading the
>> header in gcov-io.h, I wonder how it matches this pattern?
>>
>> it should be A73R, I have corrected it.
> I have tried to give some description in the code itself.
> I'll write a detailed description of each field once it's complete.
> Maybe a blog post will be nice.
>
>> 
>> Although the ident and version are formally 32 bit numbers, they
>>are derived from 4 character ASCII strings.  The version number
>>consists of a two character major version number
>>(first digit starts from 'A' letter to not to clash with the older
>>numbering scheme), the single character minor version number,
>>and a single character indicating the status of the release.
>>That will be 'e' experimental, 'p' prerelease and 'r' for release.
>>Because, by good fortune, these are in alphabetical order, string
>>collating can be used to compare version strings.  Be aware that
>>the 'e' designation will (naturally) be unstable and might be
>>incompatible with itself.  For gcc 17.0 experimental, it would be
>>'B70e' (0x42373065).  As we currently do not release more than 5 minor
>>releases, the single character should be always fine.  Major number
>>is currently changed roughly every year, which gives us space
>>for next 250 years (maximum allowed number would be 259.9).
>> 
>>
>>
>> The timestamp field also doesn't make sense to me. Assuming that
>> is a hex number, it has a LOT of digits and
>> https://www.epochconverter.com/
>> tells me that it is sometime in 2741
>>
>> There was some issue with it because I was taking signed int.
> I fixed it.
>
>> Maybe you have the endianness of some of the fields wrong.
>>
>> Yes the endianness was wrong.
> I have uploaded the code to a github repository so that it can be
> visible and progress can be trackable.
>
> https://github.com/thelunatic/gcno_dumper.git
>
> I am working on figuring out how the file is organised, I'll
> post the generated txt file soon.
>
>> But this is what it takes to understand it. :)
>>
>> --joel
>>
>>
>> On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> As suggested by Joel, I have tried to figure out the structure of
>>> the gcno files and written a gcno dumper.
>>> This is not complete yet, I'm still working on it and I'll keep adding
>>> to it as I "decode" the gcno files.
>>>
>>> I'm attaching the c++ code, the gcno file I'm testing on and the txt
>>> file generated from it.
>>>
>>> please have a look. Is it moving in the right direction ?
>>>
>>> On 12 July 2018 at 03:56, Vijay Kumar Banerjee >> > wrote:
>>>
>>>> I have filed a ticket for gcov, as suggested by Joel.
>>>>
>>>> https://devel.rtems.org/ticket/3468
>>>>
>>>> -- vijay
>>>>
>>>> On 8 July 2018 at 01:43, Chris Johns  wrote:
>>>>
>>>>> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
>>>>> > On 8 July 2018 at 01:08, Joel Sherrill >>>> j...@rtems.org>>
>>>>> > wrote:
>>>>> >
>>>>> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
>>>>> ch...@contemporary.net.au
>>>>> > <mailto:ch...@contemporary.net.au>> wrote:
>>>>> >
>>>>> > On 5 Jul 2018, at 3:07 am, Joel Sherrill >>>> > <mailto:j...@rtems.org>
>>>>> > <mailto:j...@rtems.org <mailto:j...@rt

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 18 July 2018 at 02:30, Joel Sherrill  wrote:

> This definitely looks like the right direction. If we don't understand
> the file formats, we will never be able to process and correlate them.
>
> Please put 0x in front of hex numbers. It does help.
>
> Can you explain the fields in gcno_dump.txt? The Version field
> looks like hex for R37A which doesn't make sense to me. Reading the
> header in gcov-io.h, I wonder how it matches this pattern?
>
> it should be A73R, I have corrected it.
I have tried to give some description in the code itself.
I'll write a detailed description of each field once it's complete.
Maybe a blog post will be nice.

> 
> Although the ident and version are formally 32 bit numbers, they
>are derived from 4 character ASCII strings.  The version number
>consists of a two character major version number
>(first digit starts from 'A' letter to not to clash with the older
>numbering scheme), the single character minor version number,
>and a single character indicating the status of the release.
>That will be 'e' experimental, 'p' prerelease and 'r' for release.
>Because, by good fortune, these are in alphabetical order, string
>collating can be used to compare version strings.  Be aware that
>the 'e' designation will (naturally) be unstable and might be
>incompatible with itself.  For gcc 17.0 experimental, it would be
>'B70e' (0x42373065).  As we currently do not release more than 5 minor
>releases, the single character should be always fine.  Major number
>is currently changed roughly every year, which gives us space
>for next 250 years (maximum allowed number would be 259.9).
> 
>
>
> The timestamp field also doesn't make sense to me. Assuming that
> is a hex number, it has a LOT of digits and https://www.epochconverter.
> com/
> tells me that it is sometime in 2741
>
> There was some issue with it because I was taking signed int.
I fixed it.

> Maybe you have the endianness of some of the fields wrong.
>
> Yes the endianness was wrong.
I have uploaded the code to a github repository so that it can be
visible and progress can be trackable.

https://github.com/thelunatic/gcno_dumper.git

I am working on figuring out how the file is organised, I'll
post the generated txt file soon.

> But this is what it takes to understand it. :)
>
> --joel
>
>
> On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> As suggested by Joel, I have tried to figure out the structure of
>> the gcno files and written a gcno dumper.
>> This is not complete yet, I'm still working on it and I'll keep adding
>> to it as I "decode" the gcno files.
>>
>> I'm attaching the c++ code, the gcno file I'm testing on and the txt
>> file generated from it.
>>
>> please have a look. Is it moving in the right direction ?
>>
>> On 12 July 2018 at 03:56, Vijay Kumar Banerjee 
>> wrote:
>>
>>> I have filed a ticket for gcov, as suggested by Joel.
>>>
>>> https://devel.rtems.org/ticket/3468
>>>
>>> -- vijay
>>>
>>> On 8 July 2018 at 01:43, Chris Johns  wrote:
>>>
>>>> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
>>>> > On 8 July 2018 at 01:08, Joel Sherrill >>> j...@rtems.org>>
>>>> > wrote:
>>>> >
>>>> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
>>>> ch...@contemporary.net.au
>>>> > <mailto:ch...@contemporary.net.au>> wrote:
>>>> >
>>>> > On 5 Jul 2018, at 3:07 am, Joel Sherrill >>> > <mailto:j...@rtems.org>
>>>> > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote:
>>>> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns >>> <mailto:chr...@rtems.org>
>>>> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
>>>> > >
>>>> > > How does this fit into the RTEMS Tester tool?
>>>> > >
>>>> > >
>>>> > > If you want to run gcov or lcov on uninstrumented
>>>> executables, then covoar has
>>>> > > to read gcno and write gcda files. And we have to then run
>>>> gcov or lcov as
>>>> > > normal.
>>>> >
>>>> >
>>>> > This is just a description of how it works. Not 

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

I have filed a ticket for gcov, as suggested by Joel.

https://devel.rtems.org/ticket/3468

-- vijay

On 8 July 2018 at 01:43, Chris Johns  wrote:

> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
> > On 8 July 2018 at 01:08, Joel Sherrill  j...@rtems.org>>
> > wrote:
> >
> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns  > <mailto:ch...@contemporary.net.au>> wrote:
> >
> > On 5 Jul 2018, at 3:07 am, Joel Sherrill  > <mailto:j...@rtems.org>
> > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote:
> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns  <mailto:chr...@rtems.org>
> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> > >
> > > How does this fit into the RTEMS Tester tool?
> > >
> > >
> > > If you want to run gcov or lcov on uninstrumented executables,
> then covoar has
> > > to read gcno and write gcda files. And we have to then run
> gcov or lcov as
> > > normal.
> >
> >
> > This is just a description of how it works. Not a particular change.
> >
> > >
> > > It is the path to another report format.
> >
> > I am not sure I understand how we make this work and how we
> support the
> > user. Is
> > this an option to 'rtems-test'?
> >
> > The aim of the 'rtems-test' command is to provide a documented
> user
> > interface.
> > Providing direct access to covoar adds more documentation and
> > complication to
> > the test tool. For example how does the user wanting gcov output
> get to the
> > trace files? The user would need to step into how we implement
> coverage
> > and that
> > is an interface we will not document and change.
> >
> >
> > I wouldn't want a user to invoke covoar directly. It is just a
> coverage
> > reporting variant at this point. I doubt it will ever be the default
> report
> > format because we have details in the native reports that I don't
> think you
> > can get ever with gcov. I think the native format is closer to what
> you
> > would use on an analysis for the highest level of coverage.
> >
> > once covoar can generate the gcov reports, we can add it as an option to
> rtems test.
> > we can generate a file with the list of the notes/trace files from the
> script
> > which will work as an
> > input to covoar, the user won't have to do anything manually.
>
> Thank you. I now understand.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On 11 July 2018 at 02:49, Chris Johns  wrote:

> On 11/7/18 3:18 am, Vijay Kumar Banerjee wrote:
> > On 10 July 2018 at 20:47, Gedare Bloom  > <mailto:ged...@rtems.org>> wrote:
> >
> > I don't see any problem with it, but I prefer to let Chris decide on
> merging...
> >
> > Thank you for the feedback :)
> >
>
> Sorry for the delay in responding.
>
> I suggest you leave the option as `--coverage` and consider looking at the
> `--debug-trace` option as a way to handle sets, for example
> `--coverage="sets:xyz,abc",report=gcov`.
>
> That's a good idea!
So we leave it for now and make a sub option when we have another report
format (gcov).

> The idea is to provide a single option we can add suboption parts.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

ping :)
On 6 July 2018 at 02:08, Vijay Kumar Banerjee 
wrote:

> Hello Chris,
>
> If you find some time, please review this patch.
> It's a small patch but it's important since it affects how the command
> will look like.
>
> please review if this patch is alright or we need to have a different
> approach.
>
> Thanks
> On 3 July 2018 at 20:30, Vijay Kumar Banerjee 
> wrote:
>
>> Close #3440
>> ---
>>  tester/rt/test.py| 21 ++---
>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini |  1 +
>>  2 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/rt/test.py b/tester/rt/test.py
>> index 9214ad6..5d25d82 100644
>> --- a/tester/rt/test.py
>> +++ b/tester/rt/test.py
>> @@ -232,7 +232,7 @@ def run(command_path = None):
>>  '--filter': 'Glob that executables must
>> match to run (default: ' +
>>default_exefilter + ')',
>>  '--stacktrace': 'Dump a stack trace on a user
>> termination (^C)',
>> -'--coverage':   'Perform coverage analysis of
>> test executables.'}
>> +'--coverage-sets':  'Perform coverage analysis for
>> specific sets.'}
>>  mailer.append_options(optargs)
>>  opts = options.load(sys.argv,
>>  optargs = optargs,
>> @@ -283,14 +283,21 @@ def run(command_path = None):
>>  raise error.general('RTEMS BSP not provided or an invalid
>> option')
>>  bsp = config.load(bsp[1], opts)
>>  bsp_config = opts.defaults.expand(opts.defaults['tester'])
>> -coverage_enabled = opts.find_arg('--coverage')
>> +coverage_sets = opts.find_arg('--coverage-sets')
>> +try:
>> +coverage_enabled = opts.defaults.get('coverage')
>> +except:
>> +coverage_enabled = False
>>  if coverage_enabled:
>>  cov_trace = 'cov' in debug_trace.split(',')
>> -if len(coverage_enabled) == 2:
>> -coverage_runner = coverage.coverage_run(opts.defaults,
>> -executables,
>> -symbol_set =
>> coverage_enabled[1],
>> -trace =
>> cov_trace)
>> +if coverage_sets:
>> +if len(coverage_sets) != 2:
>> +raise error.general('No sets provided in
>> --coverage-sets')
>> +else:
>> +coverage_runner = coverage.coverage_run(opts.def
>> aults,
>> +executables,
>> +symbol_set =
>> coverage_sets[1],
>> +trace =
>> cov_trace)
>>  else:
>>  coverage_runner = coverage.coverage_run(opts.defaults,
>>  executables,
>> diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> index 2f89117..6462448 100644
>> --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> @@ -38,3 +38,4 @@ target= sparc-rtems5
>>  tester= %{_rtscripts}/qemu.cfg
>>  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>>  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
>> +coverage  = True
>> --
>> 2.14.4
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 8 July 2018 at 01:08, Joel Sherrill  wrote:

>
>
> On Sat, Jul 7, 2018, 2:33 PM Chris Johns 
> wrote:
>
>> On 5 Jul 2018, at 3:07 am, Joel Sherrill > > wrote:
>> > On Wed, Jul 4, 2018, 3:06 AM Chris Johns > > > wrote:
>> >
>> > How does this fit into the RTEMS Tester tool?
>> >
>> >
>> > If you want to run gcov or lcov on uninstrumented executables, then
>> covoar has
>> > to read gcno and write gcda files. And we have to then run gcov or lcov
>> as
>> > normal.
>>
>
> This is just a description of how it works. Not a particular change.
>
> >
>> > It is the path to another report format.
>>
>> I am not sure I understand how we make this work and how we support the
>> user. Is
>> this an option to 'rtems-test'?
>>
>> The aim of the 'rtems-test' command is to provide a documented user
>> interface.
>> Providing direct access to covoar adds more documentation and
>> complication to
>> the test tool. For example how does the user wanting gcov output get to
>> the
>> trace files? The user would need to step into how we implement coverage
>> and that
>> is an interface we will not document and change.
>>
>
> I wouldn't want a user to invoke covoar directly. It is just a coverage
> reporting variant at this point. I doubt it will ever be the default report
> format because we have details in the native reports that I don't think you
> can get ever with gcov. I think the native format is closer to what you
> would use on an analysis for the highest level of coverage.
>
> once covoar can generate the gcov reports, we can add it as an option to
rtems test.
we can generate a file with the list of the notes/trace files from the
script which will work as an
input to covoar, the user won't have to do anything manually.

> The gcov reports have their own positive attributes. Particularly when you
> combine them with something like gcovr which can generate xml.
>
>>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 6 July 2018 at 23:50, Joel Sherrill  wrote:

>
>
> On Thu, Jul 5, 2018, 3:31 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I think that the whole gcov support needs to be reworked.
>>
>
> I am unsure the scope of what you have in mind.
>
>
>> I was looking into how llvm outputs their gcov data in gcda file
>> format here
>> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/
>> profile/GCDAProfiling
>>
>> <https://github.com/llvm-mirror/compiler-rt/blob/master/lib/profile/GCDAProfiling.c>
>>
>
> For normal native coverage runs, the program itself is instrumented and
> writes "records" into a buffer as it runs. On program exit, the records are
> written to the gcda file.
>
> Running cross, we don't want the object instrumented and nothing
> can be written at program exit.
>
> Understood.

>
>> <https://github.com/llvm-mirror/compiler-rt/blob/master/lib/profile/GCDAProfiling.c>
>>
>> I need some help in understanding the workflow of how covoar
>> gets the trace input and how that is dumped into a gcda file.
>>
>
> This is a purely logical description.
>
> Based on the analysis before the point the gcov generation is reached,
> you know what lines of code have been executed. This is 0/1 information
> not count which might be useful for profiling in the future.
>
> Each line is part of a basic block or arc. I am assuming that the gcno
> file gives us information on the basic blocks/arcs. covoar uses this
> information to figure out which basic block each covered instruction
> range represents. Then it writes the corresponding gcda record for
> that executed range.
>
> That looks like all the "generate gcov data" block of code is doing
> in covoar.cc.
>
> Okay, it's getting clearer gradually each day. :)

> NOTE: Every gcno file has to be processed. I assume that this code
> has a loop buried under it somewhere.
>
 Yes there's a loop inside.
My next objective it to figure out how to loop over the source file names
corresponding the the gcno file names.
I think if that works out, it will significantly get us started.

>
>
>>
>> What files are involved in the process (other than GcovData.cc and
>> GcovFunctionData.cc ) and what are their roles ?
>>
>
> That should be it from what I can tell.  You already have the
> entire set of data on what was executed. This is just a translation
> pass to saw "line x of file Y was executed". That corresponds to
> some piece of data in the gcno file and that is used to write the
> data into the gcda file which says that range was executed.
>
> We may need Martin to help us with the details of mapping source file/line
> to gcno data to gcda data but that's it.
>
Martin's help is really needed, as I can see that we're manking a lot
of assumptions about the gcno files and it's structure.
There is a possibility that the structure of the gcno files have changed
a bit, since the time this code was written, only Martin can say if we're
in the right direction with this.

The code in GcovData has some assumptions, which are mentioned in
the comments. I don't have any idea about them, Martin might need
to go through the code to help us solve them one by one.

>
>> I feel that this is very difficult to be able to do the whole work within
>> the GSoC period and the work will go on post GSoC as well.
>> So we need to set milestones specific to GSoC and then continue
>> from there post GSoC.
>>
>
> :) It's understandable. Let's just keep pushing and continue as needed.
>
> This should just be a matter of threading the pieces of information
> together.
>
> Thanks for the explanation.
We'll hopefully get it working soon. :)

> --joel
>
>
>>
>> On 5 July 2018 at 00:50, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 4 July 2018 at 22:37, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 4, 2018, 3:06 AM Chris Johns  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
>>>>>> > On 4 July 2018 at 13:09, Chris Johns >>>>> > <mailto:chr...@rtems.org>> wrote:
>>>>>> >
>>>>>> > On 4/7/18 5:38 pm, Chris Johns wrote:
>>>>>> > > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:
>>>>>> > >>
>>>>>>

Re: [PATCH v3] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

Hello Chris,

If you find some time, please review this patch.
It's a small patch but it's important since it affects how the command
will look like.

please review if this patch is alright or we need to have a different
approach.

Thanks
On 3 July 2018 at 20:30, Vijay Kumar Banerjee 
wrote:

> Close #3440
> ---
>  tester/rt/test.py| 21 ++---
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini |  1 +
>  2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 9214ad6..5d25d82 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -232,7 +232,7 @@ def run(command_path = None):
>  '--filter': 'Glob that executables must match
> to run (default: ' +
>default_exefilter + ')',
>  '--stacktrace': 'Dump a stack trace on a user
> termination (^C)',
> -'--coverage':   'Perform coverage analysis of
> test executables.'}
> +'--coverage-sets':  'Perform coverage analysis for
> specific sets.'}
>  mailer.append_options(optargs)
>  opts = options.load(sys.argv,
>  optargs = optargs,
> @@ -283,14 +283,21 @@ def run(command_path = None):
>  raise error.general('RTEMS BSP not provided or an invalid
> option')
>  bsp = config.load(bsp[1], opts)
>  bsp_config = opts.defaults.expand(opts.defaults['tester'])
> -coverage_enabled = opts.find_arg('--coverage')
> +coverage_sets = opts.find_arg('--coverage-sets')
> +try:
> +coverage_enabled = opts.defaults.get('coverage')
> +except:
> +coverage_enabled = False
>  if coverage_enabled:
>  cov_trace = 'cov' in debug_trace.split(',')
> -if len(coverage_enabled) == 2:
> -coverage_runner = coverage.coverage_run(opts.defaults,
> -executables,
> -symbol_set =
> coverage_enabled[1],
> -trace = cov_trace)
> +if coverage_sets:
> +if len(coverage_sets) != 2:
> +raise error.general('No sets provided in
> --coverage-sets')
> +else:
> +coverage_runner = coverage.coverage_run(opts.
> defaults,
> +executables,
> +symbol_set =
> coverage_sets[1],
> +trace =
> cov_trace)
>  else:
>  coverage_runner = coverage.coverage_run(opts.defaults,
>  executables,
> diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> index 2f89117..6462448 100644
> --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> @@ -38,3 +38,4 @@ target= sparc-rtems5
>  tester= %{_rtscripts}/qemu.cfg
>  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
> +coverage  = True
> --
> 2.14.4
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] tester/covoar/coverage_converter.cc: Fix typo

[Vijay Kumar Banerjee]

---
 tester/covoar/coverage_converter.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/covoar/coverage_converter.cc 
b/tester/covoar/coverage_converter.cc
index 8144d93..fffa2d6 100644
--- a/tester/covoar/coverage_converter.cc
+++ b/tester/covoar/coverage_converter.cc
@@ -73,7 +73,7 @@ void usage()
 "Usage: %s [-v] -l ADDRESS -h ADDRESS coverage_in coverage_out\n"
 "\n"
 "  -l low address   - low address of range to merge\n"
-"  -l high address  - high address of range to merge\n"
+"  -h high address  - high address of range to merge\n"
 "  -f format- coverage files are in  (Qemu)\n"
 "  -v   - verbose at initialization\n"
 "\n",
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 4 July 2018 at 13:36, Chris Johns  wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > On 4 July 2018 at 13:09, Chris Johns  > <mailto:chr...@rtems.org>> wrote:
> >
> > On 4/7/18 5:38 pm, Chris Johns wrote:
> > > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:
> > >>
> > >> I'm starting this thread for discussions on the gcov support
> > >> in covoar.
> > >>
> > >> Current status is that the code in it (like in GcovData.cc)
> remained untouched
> > >> for a long time and it had not been updated after the source
> tree reorganization
> > >> which is why it runs into segmentation
> > >> fault while trying to find the source files.
> > >>
> > >> Joel was suggesting to copy the file gcov-io.h from the gcc
> > >> source after a license discussion here.
> > >
> > > What license the file's license?
> >
> > Sorry .. What is the file's license?
> >
> > GPL version 3
>
> This license is not suitable.
>
> > > We are aiming to have all code under the RTEMS Tools under a BSD
> or compatible
> > > license. Are there other options that have a more suitable license?
> > >
> > > Also, could you please explain how gcov fits into the coverage
> testing?
> > >
> >
> > gcov is a test coverage program by gcc that generates
> statement-by-statement
> > profiling.
> > (https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html)
>
> Yes.
>
> > once we're able to generate gcov reports we can run graphical tools like
> lcov or
> > gcovr to generate html and xml reports with detailed coverage data.
> > an example of lcov report:
> > http://ltp.sourceforge.net/coverage/lcov/output/example/
> methods/iterate.c.gcov.html
> >
>
> Do you want to export gcov files from the other trace formats we handle?
>
> How does this fit into the RTEMS Tester tool?
>
>
this is a basic outline of the plan :

   - gcc generates the .gcno notes file at the compile time
   - covoar reads these gcno files and the trace files from qemu and
   produces the gcda files that can be processed by gcov.
   - gcov processes gcno and gcda files to produce coverage reports.



> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 4 July 2018 at 13:09, Chris Johns  wrote:

> On 4/7/18 5:38 pm, Chris Johns wrote:
> > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:
> >>
> >> I'm starting this thread for discussions on the gcov support
> >> in covoar.
> >>
> >> Current status is that the code in it (like in GcovData.cc) remained
> untouched
> >> for a long time and it had not been updated after the source
> tree reorganization
> >> which is why it runs into segmentation
> >> fault while trying to find the source files.
> >>
> >> Joel was suggesting to copy the file gcov-io.h from the gcc
> >> source after a license discussion here.
> >
> > What license the file's license?
>
> Sorry .. What is the file's license?
>
> GPL version 3

> >
> > We are aiming to have all code under the RTEMS Tools under a BSD or
> compatible
> > license. Are there other options that have a more suitable license?
> >
> > Also, could you please explain how gcov fits into the coverage testing?
> >
>
gcov is a test coverage program by gcc that generates
statement-by-statement profiling.
(https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html)

once we're able to generate gcov reports we can run graphical tools like
lcov or gcovr
to generate html and xml reports with detailed coverage data.
an example of lcov report:
http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html

> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Gcov support in Covoar

[Vijay Kumar Banerjee]

Hello,

I'm starting this thread for discussions on the gcov support
in covoar.

Current status is that the code in it (like in GcovData.cc) remained
untouched
for a long time and it had not been updated after the source
tree reorganization which is why it runs into segmentation
fault while trying to find the source files.

Joel was suggesting to copy the file gcov-io.h from the gcc
source after a license discussion here.

Thanks
-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

Close #3440
---
 tester/rt/test.py| 21 ++---
 tester/rtems/testing/bsps/leon3-qemu-cov.ini |  1 +
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9214ad6..5d25d82 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -232,7 +232,7 @@ def run(command_path = None):
 '--filter': 'Glob that executables must match to 
run (default: ' +
   default_exefilter + ')',
 '--stacktrace': 'Dump a stack trace on a user 
termination (^C)',
-'--coverage':   'Perform coverage analysis of test 
executables.'}
+'--coverage-sets':  'Perform coverage analysis for 
specific sets.'}
 mailer.append_options(optargs)
 opts = options.load(sys.argv,
 optargs = optargs,
@@ -283,14 +283,21 @@ def run(command_path = None):
 raise error.general('RTEMS BSP not provided or an invalid option')
 bsp = config.load(bsp[1], opts)
 bsp_config = opts.defaults.expand(opts.defaults['tester'])
-coverage_enabled = opts.find_arg('--coverage')
+coverage_sets = opts.find_arg('--coverage-sets')
+try:
+coverage_enabled = opts.defaults.get('coverage')
+except:
+coverage_enabled = False
 if coverage_enabled:
 cov_trace = 'cov' in debug_trace.split(',')
-if len(coverage_enabled) == 2:
-coverage_runner = coverage.coverage_run(opts.defaults,
-executables,
-symbol_set = 
coverage_enabled[1],
-trace = cov_trace)
+if coverage_sets:
+if len(coverage_sets) != 2:
+raise error.general('No sets provided in --coverage-sets')
+else:
+coverage_runner = coverage.coverage_run(opts.defaults,
+executables,
+symbol_set = 
coverage_sets[1],
+trace = cov_trace)
 else:
 coverage_runner = coverage.coverage_run(opts.defaults,
 executables,
diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini 
b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
index 2f89117..6462448 100644
--- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
@@ -38,3 +38,4 @@ target= sparc-rtems5
 tester= %{_rtscripts}/qemu.cfg
 bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
 bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
+coverage  = True
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Query regarding covoar

[Vijay Kumar Banerjee]

On Tue, 3 Jul 2018, 04:32 Joel Sherrill,  wrote:

>
>
> On Mon, Jul 2, 2018 at 5:50 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I wanted some help in understanding the
>> function of the following files in covoar
>>
>> 1. qemu-dump-trace.c
>>
>
> Print the couverture trace file in human readable format. Ensure that
> covoar can read it correctly. This is the main() for a utility.
>
> If gcc doesn't have one, a gcno and gcda dump would be comparable
> and useful utilities.
>
>
how to run this ?

> 2. CoverageReaderQEMU.cc
>>
>
> Read a Qemu trace and put it into a coverage map. This is an
> input converter. Each supported trace format (e.g. qemu, tsim)
> has a reader class.
>
> For some formats, there is also a Writer class. The Coverage
> RTEMS format was intended for debugging and interchange
> with TBD tools.
>
>
>> 3. TraceConverter.cc
>>
>
>  This is a simple utility which uses a reader and writer instance
> to read from one format and write to another. This was envisioned
> to help interoperate with tools which only knew one coverage format.
> Say you ran qemu but had tools to process tsim coverage files.
> Convert them.
>
> Note: Trace files like qemu have more information available than
> bit map coverage files like tsim or skyeye.
>
Thank you for the answer, I will come up with more questions
as I dig deeper. :)

>
>
>>
>> If the information I'm seeking is already
>> present in a documentation, the link to
>> the doc would be helpful. :)
>>
>
> Everyone's a comedian. This stuff needs more documentation. :)
>
> Badly. Maybe the summer of code is followed by you and I having
> a winter of documentation.
>
This really needs more documentation.
I'm up for the WOD. ;)

>
> --joel
>
>>
>> Thanks
>> --vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Query regarding covoar

[Vijay Kumar Banerjee]

Hello,

I wanted some help in understanding the
function of the following files in covoar

1. qemu-dump-trace.c
2. CoverageReaderQEMU.cc
3. TraceConverter.cc

If the information I'm seeking is already
present in a documentation, the link to
the doc would be helpful. :)

Thanks
--vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

Close #3440
---
 tester/rt/test.py| 21 ++---
 tester/rtems/testing/bsps/leon3-qemu-cov.ini |  1 +
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 9214ad6..029ee7c 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -232,7 +232,7 @@ def run(command_path = None):
 '--filter': 'Glob that executables must match to 
run (default: ' +
   default_exefilter + ')',
 '--stacktrace': 'Dump a stack trace on a user 
termination (^C)',
-'--coverage':   'Perform coverage analysis of test 
executables.'}
+'--coverage-sets':  'Perform coverage analysis of test 
executables.'}
 mailer.append_options(optargs)
 opts = options.load(sys.argv,
 optargs = optargs,
@@ -283,14 +283,21 @@ def run(command_path = None):
 raise error.general('RTEMS BSP not provided or an invalid option')
 bsp = config.load(bsp[1], opts)
 bsp_config = opts.defaults.expand(opts.defaults['tester'])
-coverage_enabled = opts.find_arg('--coverage')
+coverage_sets = opts.find_arg('--coverage-sets')
+try:
+coverage_enabled=opts.defaults.get('coverage')
+except:
+coverage_enabled=False
 if coverage_enabled:
 cov_trace = 'cov' in debug_trace.split(',')
-if len(coverage_enabled) == 2:
-coverage_runner = coverage.coverage_run(opts.defaults,
-executables,
-symbol_set = 
coverage_enabled[1],
-trace = cov_trace)
+if coverage_sets:
+if len(coverage_sets)!= 2:
+raise error.general('No sets provided in --coverage-sets')
+else:
+coverage_runner = coverage.coverage_run(opts.defaults,
+executables,
+symbol_set = 
coverage_sets[1],
+trace = cov_trace)
 else:
 coverage_runner = coverage.coverage_run(opts.defaults,
 executables,
diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini 
b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
index 2f89117..6462448 100644
--- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
+++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
@@ -38,3 +38,4 @@ target= sparc-rtems5
 tester= %{_rtscripts}/qemu.cfg
 bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
 bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
+coverage  = True
-- 
2.14.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On 15 June 2018 at 08:38, Chris Johns  wrote:

> On 14/06/2018 03:12, Gedare Bloom wrote:
> > On Wed, Jun 13, 2018 at 12:23 PM, Vijay Kumar Banerjee
> >  wrote:
> >> On Wed, 13 Jun 2018, 21:39 Gedare Bloom,  wrote:
> >>> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee
> >>>  wrote:
> >>>> On 13 June 2018 at 10:29, Gedare Bloom  wrote:
> >>>>> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
> >>>>>  wrote:
> >>>>>>  bsp = opts.find_arg('--rtems-bsp')
> >>>>>> +if 'cov' in bsp[1].split('-'):
> >>>>>
> >>>>> I'm not sure if this use of the 'cov' field in the bsp config
> filename
> >>>>> itself is the proper way to go about accomplishing the activation of
> >>>>> coverage. What are other possible ways to get this done? Is the use
> of
> >>>>> a portion of the bsp config filename done elsewhere in tester?
> >>>>
> >>>> This patch was made following Chris' comments in another thread
> >>>>
> >>>> https://lists.rtems.org/pipermail/devel/2018-June/021931.html
> >>>>
> >>>
> >>> I can't be sure, but I don't think his intent was to infer the
> >>> coverage from the ini file name.
>
> Correct.
>
> >>> For example, does the tester parse
> >>> the ini file name to check for 'qemu' to decide if that target is
> >>> being used? Instead, it should look in to the config file to read the
> >>> option somehow.
> >>
> >> In leon3-qemu.ini the bsp option inside the
> >> config file is set to leon3-qemu.
> >>
> >> There's no such special thing added to bsp for coverage.
> >> Only difference we have is that,
> >> the option 'bsp_qemu_cov_opts' is added in the coverage supported file.
> we
> >> can
> >> read the config file to see if this option is present.
> >>
> >> Shall I do it this way?
> >
> > Yes, I suspect you should.
> >
>
> Can we have 'coverage = true' in the INI file to indicate this BSP supports
> coverage?
>
> >>>
> >>>>>
> >>>>>> +coverage_enabled = True
>
> And that values maps to here.
>
> As the covoar patches are merged, shall I send a patch with the
coverage=true option ?

> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On 24 June 2018 at 11:11, Chris Johns  wrote:

> On 24/06/2018 14:54, Chris Johns wrote:
> > On 24/06/2018 12:35, Chris Johns wrote:
> >> On 23/06/2018 05:10, Vijay Kumar Banerjee wrote:
> >>> I'm running rtems-test with the following command
> >>>
> >>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test \
> >>> --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log \
> >>> --no-clean --coverage=score --rtems-bsp=leon3-qemu-cov \
> >>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/
> leon3/testsuites/samples
> >>>
> >>> I'm getting this error
> >>>
> >>> -
> >>> error: coverage: covoar failure:: -11
> >>
> >
> > I am seeing this as well on FreeBSD. Running lldb I am seeing:
> >
> > Process 40657 stopped
> > * thread #1, stop reason = signal SIGSEGV: invalid address (fault
> address: 0x4)
> > frame #0: covoar`dwarf_global_formref(at=0x0004,
> > return_offset=0x7fffc6d8, error=0x7fffbea8) at
> dwarf_form.c:142
> >139  int ret;
> >140  Dwarf_Debug dbg;
> >141
> > -> 142  dbg = at != NULL ? at->at_die->die_dbg : NULL;
> >143
> >144  if (at == NULL || return_offset == NULL) {
> >145  DWARF_SET_ERROR(dbg, error, DW_DLE_ARGUMENT);
> >
> > Something is wrong in the toolkit DWARF loading of functions.
> >
>
> I have pushed a fix on master. Please update.
>
> after pulling the fix from master, it's working fine. I can see proper
reports.

> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[ GSoC coverage ] weekly project status update

[Vijay Kumar Banerjee]

Hello,

This week I spent some time trying to build the leon3 bsp with -Os and
-ftest-coverage
options. I was getting a lot of errors with this, I tried to build with -O0
option,
and it build properly. Gedare pointed in the last meeting that this might
be an error
with the compiler.

I experimented with the gcov arguments to covoar. I _do_ see gcda files
generated
by covoar but they don't have any data, there's some error in reading the
gcno files
by covoar.  This week I would look into the GcovData.cc and look into the
errors.

I have one question.
Once we get proper gcda data from covoar, can we separately run lcov on the
gcda files?
-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On Tue, 19 Jun 2018, 08:54 Chris Johns,  wrote:

> On 19/06/2018 13:16, Vijay Kumar Banerjee wrote:
> > I would like to get my 22 patches pushed to master before moving on
> this topic.
> > This is the report I generate:
> >
> >
> https://ftp.rtems.org/pub/rtems/people/chrisj/coverage/leon3/leon3-qemu-report.html
> >
> > How does this look?
> >
> > The report looks good.
> > This report is from two subsystems score and rtems
> > that are mentioned in the symbols ini file.
>
> Excellent, I will push the patches. I have just run all the samples and
> updated
> the report.
>
Awesome! report looks good.

>
> I get the size warning ...
>
Yes, I'm getting these warnings as well.

>
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage
> maps for _Workspace_Allocate_or_fatal_error with different sizes
>
> (/opt/work/chris/rtems/kernel/bsps/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture.exe/80!=
>
> /opt/work/chris/rtems/kernel/bsps/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp.exe/60)
>
> My version of covoar has the DWARF function details from for a CU for an
> executable so it will be interesting to see what this shows. I will take a
> look
> at some point.
>
I was hoping that these warnings would go away after your covoar patches

>
> Also the execute wrapper needs to catch stderr and redirect that to the
> log. I
> will take a look at that.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On Tue, 19 Jun 2018, 05:32 Chris Johns,  wrote:

> On 16/06/2018 02:55, Vijay Kumar Banerjee wrote:
> > On Fri, 15 Jun 2018, 08:39 Chris Johns,  > <mailto:chr...@rtems.org>> wrote:
> > On 14/06/2018 03:12, Gedare Bloom wrote:
> > > On Wed, Jun 13, 2018 at 12:23 PM, Vijay Kumar Banerjee
> > > mailto:vijaykumar9...@gmail.com>>
> wrote:
> > >> On Wed, 13 Jun 2018, 21:39 Gedare Bloom,  > <mailto:ged...@rtems.org>> wrote:
> > >>> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee
> > >>> mailto:vijaykumar9...@gmail.com>>
> wrote:
> > >>>> On 13 June 2018 at 10:29, Gedare Bloom  > <mailto:ged...@rtems.org>> wrote:
> > >>>>> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
> > >>>>> mailto:vijaykumar9...@gmail.com>>
> wrote:
> > >>>>>>  bsp = opts.find_arg('--rtems-bsp')
> > >>>>>> +if 'cov' in bsp[1].split('-'):
> > >>>>>
> > >>>>> I'm not sure if this use of the 'cov' field in the bsp config
> filename
> > >>>>> itself is the proper way to go about accomplishing the
> activation of
> > >>>>> coverage. What are other possible ways to get this done? Is
> the use of
> > >>>>> a portion of the bsp config filename done elsewhere in tester?
> > >>>>
> > >>>> This patch was made following Chris' comments in another thread
> > >>>>
> > >>>> https://lists.rtems.org/pipermail/devel/2018-June/021931.html
> > <https://lists.rtems.org/pipermail/devel/2018-June/021931.html>
> > >>>>
> > >>>
> > >>> I can't be sure, but I don't think his intent was to infer the
> > >>> coverage from the ini file name.
> >
> > Correct.
> >
> > >>> For example, does the tester parse
> > >>> the ini file name to check for 'qemu' to decide if that target is
> > >>> being used? Instead, it should look in to the config file to
> read the
> > >>> option somehow.
> > >>
> > >> In leon3-qemu.ini the bsp option inside the
> > >> config file is set to leon3-qemu.
> > >>
> > >> There's no such special thing added to bsp for coverage.
> > >> Only difference we have is that,
> > >> the option 'bsp_qemu_cov_opts' is added in the coverage supported
> file. we
> > >> can
> > >> read the config file to see if this option is present.
> > >>
> > >> Shall I do it this way?
> > >
> > > Yes, I suspect you should.
> > >
> >
> > Can we have 'coverage = true' in the INI file to indicate this BSP
> supports
> > coverage?
> >
> > We can do it.
> >
> > In the other thread, there were discussions on adding a section
> 'coverage'
> > to the ini file, and give all the coverage related options under it.
> >
> > What do you think of that approach ?
> >
>
> I am not sure at the moment. We have a cov INI file per BSP so it is not
> clear
> to me if we need a separate section.
>
> I would like to get my 22 patches pushed to master before moving on this
> topic.
> This is the report I generate:
>
>
> https://ftp.rtems.org/pub/rtems/people/chrisj/coverage/leon3/leon3-qemu-report.html
>
> How does this look?
>
The report looks good.
This report is from two subsystems score and rtems
that are mentioned in the symbols ini file.

>
> Chruis
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building from RSB

[Vijay Kumar Banerjee]

On 16 June 2018 at 01:50, Gedare Bloom  wrote:

> Hello there,
>
> someone on IRC mentions that www.gaisler.com works still. Maybe try
> changing the URL to that one?
>
> https://www.gaisler.com/gdb/gdb-8.0.1-sis-leon2-leon3.diff
returns 404

> On Fri, Jun 15, 2018 at 1:09 PM, Vijay Kumar Banerjee
>  wrote:
> >
> >
> > On Fri, 15 Jun 2018, 22:35 Cillian O'Donnell, 
> wrote:
> >>
> >>
> >>
> >> On Fri, 15 Jun 2018 at 17:49, Vijay Kumar Banerjee
> >>  wrote:
> >>>
> >>> Hello,
> >>>
> >>> While trying to freshly build RTEMS from RSB with the following command
> >>>
> >>> `../source-builder/sb-set-builder \
> >>> --prefix=/home/lunatic/development/rtems/5 5/rtems-sparc"
> >>>
> >>> I'm getting the following error :
> >>>
> >>>  --
> >>> error: downloading
> >>> https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff: all paths have
> >>> failed, giving up
> >>> Build FAILED
> >>> --
> >>
> >>
> >> Yeah gailser.org does seem to be down. You could grep for that patch in
> >> rsb and comment it out and just build without it. You're using qemu to
> run
> >> it so I don't think the gdb patch is necessary.
> >
> > Will do it. Thanks. :)
> >>>
> >>>
> >>> The url doesn't seem to work when I open from browser.
> >>>
> >>>
> >>> -- vijay
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building from RSB

[Vijay Kumar Banerjee]

On Fri, 15 Jun 2018, 22:35 Cillian O'Donnell,  wrote:

>
>
> On Fri, 15 Jun 2018 at 17:49, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> While trying to freshly build RTEMS from RSB with the following command
>>
>> `../source-builder/sb-set-builder \
>> --prefix=/home/lunatic/development/rtems/5 5/rtems-sparc"
>>
>> I'm getting the following error :
>>
>>  --
>> error: downloading https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff:
>> all paths have failed, giving up
>> Build FAILED
>> --
>>
>
> Yeah gailser.org does seem to be down. You could grep for that patch in
> rsb and comment it out and just build without it. You're using qemu to run
> it so I don't think the gdb patch is necessary.
>
Will do it. Thanks. :)

>
>> The url doesn't seem to work when I open from browser.
>>
>>
>> -- vijay
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On Fri, 15 Jun 2018, 08:39 Chris Johns,  wrote:

> On 14/06/2018 03:12, Gedare Bloom wrote:
> > On Wed, Jun 13, 2018 at 12:23 PM, Vijay Kumar Banerjee
> >  wrote:
> >> On Wed, 13 Jun 2018, 21:39 Gedare Bloom,  wrote:
> >>> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee
> >>>  wrote:
> >>>> On 13 June 2018 at 10:29, Gedare Bloom  wrote:
> >>>>> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
> >>>>>  wrote:
> >>>>>>  bsp = opts.find_arg('--rtems-bsp')
> >>>>>> +if 'cov' in bsp[1].split('-'):
> >>>>>
> >>>>> I'm not sure if this use of the 'cov' field in the bsp config
> filename
> >>>>> itself is the proper way to go about accomplishing the activation of
> >>>>> coverage. What are other possible ways to get this done? Is the use
> of
> >>>>> a portion of the bsp config filename done elsewhere in tester?
> >>>>
> >>>> This patch was made following Chris' comments in another thread
> >>>>
> >>>> https://lists.rtems.org/pipermail/devel/2018-June/021931.html
> >>>>
> >>>
> >>> I can't be sure, but I don't think his intent was to infer the
> >>> coverage from the ini file name.
>
> Correct.
>
> >>> For example, does the tester parse
> >>> the ini file name to check for 'qemu' to decide if that target is
> >>> being used? Instead, it should look in to the config file to read the
> >>> option somehow.
> >>
> >> In leon3-qemu.ini the bsp option inside the
> >> config file is set to leon3-qemu.
> >>
> >> There's no such special thing added to bsp for coverage.
> >> Only difference we have is that,
> >> the option 'bsp_qemu_cov_opts' is added in the coverage supported file.
> we
> >> can
> >> read the config file to see if this option is present.
> >>
> >> Shall I do it this way?
> >
> > Yes, I suspect you should.
> >
>
> Can we have 'coverage = true' in the INI file to indicate this BSP supports
> coverage?
>
We can do it.

In the other thread, there were discussions on adding a section 'coverage'
to the ini file, and give all the coverage related options under it.

What do you think of that approach ?

>
> >>>
> >>>>>
> >>>>>> +coverage_enabled = True
>
> And that values maps to here.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

error while building from RSB

[Vijay Kumar Banerjee]

Hello,

While trying to freshly build RTEMS from RSB with the following command

`../source-builder/sb-set-builder \
--prefix=/home/lunatic/development/rtems/5 5/rtems-sparc"

I'm getting the following error :

 --
error: downloading https://gaisler.org/gdb/gdb-8.0.1-sis-leon2-leon3.diff:
all paths have failed, giving up
Build FAILED
--

The url doesn't seem to work when I open from browser.


-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On Wed, 13 Jun 2018, 21:39 Gedare Bloom,  wrote:

> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee
>  wrote:
> > On 13 June 2018 at 10:29, Gedare Bloom  wrote:
> >>
> >> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
> >>  wrote:
> >> > Close #3440
> >> > ---
> >> >  tester/rt/coverage.py |  6 --
> >> >  tester/rt/test.py | 15 ++-
> >> >  2 files changed, 14 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> >> > index 54933d5..af24124 100644
> >> > --- a/tester/rt/coverage.py
> >> > +++ b/tester/rt/coverage.py
> >> > @@ -163,7 +163,8 @@ class report_gen_html:
> >> >  row += " " + summary.branches_uncovered + ""
> >> >  row += " " + summary.branches_total + ""
> >> >  row += "  {:.3%}
> >> > ".format(summary.percentage_branches_covered)
> >> > -row += '  >> >
> max="100">'.format(100*summary.percentage_branches_covered)
> >> > +row += '  >> > max="100">'\
> >> > +.format(100*summary.percentage_branches_covered)
> >>
> >> Is there a style guide for how to split long lines in Python? I find
> >> splitting before the .format seems strange to me. I might have
> >> preferred to see it split at .format(\ which probably can be done
> >> without using a backslash in this case, since python knows to keep
> >> scanning inside a parenthetical block.
> >
> > Will update it according to your suggestion. :)
> >>
> >>
> >> >  row += "\n"
> >> >  return row
> >> >
> >> > @@ -299,7 +300,8 @@ class covoar(object):
> >> >  if (not path.exists(covoar_result_dir)):
> >> >  path.mkdir(covoar_result_dir)
> >> >  if (not path.exists(symbol_file)):
> >> > -raise error.general('symbol set file: coverage %s was not
> >> > created for covoar, skipping %s'% (symbol_file, set_name))
> >> > +raise error.general('symbol set file: %s was not '
> >> > +'created for covoar, skipping %s'% (symbol_file,
> >> > set_name))
> >>
> >> ditto.
> >>
> >> >  command = ('covoar -S ' + symbol_file
> >> >+ ' -O ' + covoar_result_dir
> >> >+ ' -E ' + self.explanations_txt
> >> > diff --git a/tester/rt/test.py b/tester/rt/test.py
> >> > index 0e744cd..cdb5157 100644
> >> > --- a/tester/rt/test.py
> >> > +++ b/tester/rt/test.py
> >> > @@ -232,7 +232,7 @@ def run(command_path = None):
> >> >  '--filter': 'Glob that executables must
> >> > match to run (default: ' +
> >> >default_exefilter + ')',
> >> >  '--stacktrace': 'Dump a stack trace on a user
> >> > termination (^C)',
> >> > -'--coverage':   'Perform coverage analysis of
> >> > test executables.'}
> >> > +'--coverage-sets':  'Perform coverage for
> specific
> >> > sets'}
> >> >  mailer.append_options(optargs)
> >> >  opts = options.load(sys.argv,
> >> >  optargs = optargs,
> >> > @@ -279,15 +279,20 @@ def run(command_path = None):
> >> >  else:
> >> >  rtems_tools = '%{_prefix}'
> >> >  bsp = opts.find_arg('--rtems-bsp')
> >> > +if 'cov' in bsp[1].split('-'):
> >>
> >> I'm not sure if this use of the 'cov' field in the bsp config filename
> >> itself is the proper way to go about accomplishing the activation of
> >> coverage. What are other possible ways to get this done? Is the use of
> >> a portion of the bsp config filename done elsewhere in tester?
> >
> > This patch was made following Chris' comments in another thread
> >
> > https://lists.rtems.org/pipermail/devel/2018-June/021931.html
> >
>
> I can't be sure, but I don't think his intent was to infer the
> coverage from the ini file name. For example, does the tester parse
> the ini file name to check for 'qemu' to decide if that target is
> being

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On 13 June 2018 at 10:29, Gedare Bloom  wrote:

> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee
>  wrote:
> > Close #3440
> > ---
> >  tester/rt/coverage.py |  6 --
> >  tester/rt/test.py | 15 ++-
> >  2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > index 54933d5..af24124 100644
> > --- a/tester/rt/coverage.py
> > +++ b/tester/rt/coverage.py
> > @@ -163,7 +163,8 @@ class report_gen_html:
> >  row += " " + summary.branches_uncovered + ""
> >  row += " " + summary.branches_total + ""
> >  row += "  {:.3%} ".format(summary.
> percentage_branches_covered)
> > -row += '  max="100">'.format(100*summary.percentage_
> branches_covered)
> > +row += '  max="100">'\
> > +.format(100*summary.percentage_branches_covered)
>
> Is there a style guide for how to split long lines in Python? I find
> splitting before the .format seems strange to me. I might have
> preferred to see it split at .format(\ which probably can be done
> without using a backslash in this case, since python knows to keep
> scanning inside a parenthetical block.
>
Will update it according to your suggestion. :)

>
> >  row += "\n"
> >  return row
> >
> > @@ -299,7 +300,8 @@ class covoar(object):
> >  if (not path.exists(covoar_result_dir)):
> >  path.mkdir(covoar_result_dir)
> >  if (not path.exists(symbol_file)):
> > -raise error.general('symbol set file: coverage %s was not
> created for covoar, skipping %s'% (symbol_file, set_name))
> > +raise error.general('symbol set file: %s was not '
> > +'created for covoar, skipping %s'% (symbol_file,
> set_name))
>
> ditto.
>
> >  command = ('covoar -S ' + symbol_file
> >+ ' -O ' + covoar_result_dir
> >+ ' -E ' + self.explanations_txt
> > diff --git a/tester/rt/test.py b/tester/rt/test.py
> > index 0e744cd..cdb5157 100644
> > --- a/tester/rt/test.py
> > +++ b/tester/rt/test.py
> > @@ -232,7 +232,7 @@ def run(command_path = None):
> >  '--filter': 'Glob that executables must
> match to run (default: ' +
> >default_exefilter + ')',
> >  '--stacktrace': 'Dump a stack trace on a user
> termination (^C)',
> > -'--coverage':   'Perform coverage analysis of
> test executables.'}
> > +'--coverage-sets':  'Perform coverage for specific
> sets'}
> >  mailer.append_options(optargs)
> >  opts = options.load(sys.argv,
> >  optargs = optargs,
> > @@ -279,15 +279,20 @@ def run(command_path = None):
> >  else:
> >  rtems_tools = '%{_prefix}'
> >  bsp = opts.find_arg('--rtems-bsp')
> > +if 'cov' in bsp[1].split('-'):
>
> I'm not sure if this use of the 'cov' field in the bsp config filename
> itself is the proper way to go about accomplishing the activation of
> coverage. What are other possible ways to get this done? Is the use of
> a portion of the bsp config filename done elsewhere in tester?
>
This patch was made following Chris' comments in another thread

https://lists.rtems.org/pipermail/devel/2018-June/021931.html


> > +coverage_enabled = True
> >  if bsp is None or len(bsp) != 2:
> >  raise error.general('RTEMS BSP not provided or an invalid
> option')
> >  bsp = config.load(bsp[1], opts)
> >  bsp_config = opts.defaults.expand(opts.defaults['tester'])
> > -coverage_enabled = opts.find_arg('--coverage')
> > +coverage_sets = opts.find_arg('--coverage-sets')
> >  if coverage_enabled:
> > -if len(coverage_enabled) == 2:
> > -coverage_runner = coverage.coverage_run(opts.defaults,
> > -coverage_enabled[1],
> > +if coverage_sets:
> > +if len(coverage_sets) != 2:
> > +raise error.general('No sets provided in
> --coverage-sets')
> > +else :
>
> I don't think there should be a space character before the colon?
>
that's a mistake, I'll correct it. Thanks.

>
> > +coverage_runner = coverage.coverage_run(opts.
> defaults,
> > +coverage_sets[1],
> >  executables)
> >  else:
> >  coverage_runner = coverage.coverage_run(opts.defaults,
> 0,
> > --
> > 2.14.3
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Wed, 13 Jun 2018, 11:51 Joel Sherrill,  wrote:

>
>
> On Sun, Jun 10, 2018, 6:02 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Sun, 10 Jun 2018, 20:52 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Sat, Jun 9, 2018, 6:02 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 10 June 2018 at 04:16, Joel Sherrill  wrote:
>>>>
>>>>> I suggest this because it is a work around for you. The long term
>>>>> solution could be to add the symbol to newlib's dummy RTEMS crt0.c, add it
>>>>> to librtemscpu.a (which is the temporary hack I suggested), add a 
>>>>> libgcov.a
>>>>> implementation or stub to RTEMS, or modify GCC.
>>>>>
>>>>> Up until now, we have avoided gcc options which altered the code under
>>>>> test. Test as you fly, fly as you test. This hints at a problem we need to
>>>>> think through. Is the call actually needed? I don't know.
>>>>>
>>>>> (according to my understanding)
>>>> To generate the gcov reports we would need it .
>>>> the -ftest-coverage generates a gcno file that contains information
>>>> about each branch in the code.
>>>> a code compiled with -fprofile-arcs includes libgcov which
>>>> gets invoked during the program exit. The coverage information is
>>>> collected during runtime and dumped into gcda file by libgcov.
>>>>
>>>
>>> We don't need it to gather its own information. Covoar generates it
>>> based on the execution trace. If all this option does is instrument the
>>> generated code and write results on exit, then we want to turn that off and
>>> teach covoar to write the same files.
>>>
>> Yes that's all the option does.
>> Understood. I'll try to figure out how the
>> gcov code in covoar works/is supposed
>> to work.
>>
>
> Just remember that we want no changes to the code running on the target.
> So covoar has to generate any output like profiling, coverage days, etc.
> from the qemu traces. I know that helps me keep it clear.
>
Understood.

>
> As to the build error, make sure you have a fresh build with no
> unnecessary changes to compile flags.
>
Okay, will try again.

>
>
>>> On Sat, Jun 9, 2018, 5:38 PM Joel Sherrill  wrote:
>>>>>
>>>>>> For now, add a file to libcsupport/src which provides the symbols
>>>>>> needed. Make sure things are methods or data as needed. Check GCC source
>>>>>> for the prototype.
>>>>>>
>>>>>> This looks like something that is going to need a lot of reading.
>>>>
>>>>> On Sat, Jun 9, 2018, 3:34 PM Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 10 June 2018 at 01:28, Joel Sherrill  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 10 June 2018 at 00:55, Joel Sherrill  wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee <
>>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 9 June 2018 at 19:56, Joel Sherrill  wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
>>>>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was going through the gcc manual for gcov
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization
>>>>>>>>>>>>>
>>>>>>>>>>>>> It mentions that the flag -fprofile-arcs is ne

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

On Tue, 12 Jun 2018, 12:27 Joel Sherrill,  wrote:

> Chris needs to speak up since it is Python.
>
> I see changes to HTML output which I doubt are related to the core change.
>
There are no real changes to HTML,
I have just added line breaks in the code
because it was too long.

>
> On Tue, Jun 12, 2018, 8:39 AM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Please review this patch. :)
>> On 7 June 2018 at 16:38, Vijay Kumar Banerjee 
>> wrote:
>>
>>> Close #3440
>>> ---
>>>  tester/rt/coverage.py |  6 --
>>>  tester/rt/test.py | 15 ++-
>>>  2 files changed, 14 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>> index 54933d5..af24124 100644
>>> --- a/tester/rt/coverage.py
>>> +++ b/tester/rt/coverage.py
>>> @@ -163,7 +163,8 @@ class report_gen_html:
>>>  row += " " + summary.branches_uncovered + ""
>>>  row += " " + summary.branches_total + ""
>>>  row += "  {:.3%}
>>> ".format(summary.percentage_branches_covered)
>>> -row += ' >> max="100">'.format(100*summary.percentage_branches_covered)
>>> +row += ' >> max="100">'\
>>> +.format(100*summary.percentage_branches_covered)
>>>  row += "\n"
>>>  return row
>>>
>>> @@ -299,7 +300,8 @@ class covoar(object):
>>>  if (not path.exists(covoar_result_dir)):
>>>  path.mkdir(covoar_result_dir)
>>>  if (not path.exists(symbol_file)):
>>> -raise error.general('symbol set file: coverage %s was not
>>> created for covoar, skipping %s'% (symbol_file, set_name))
>>> +raise error.general('symbol set file: %s was not '
>>> +'created for covoar, skipping %s'% (symbol_file,
>>> set_name))
>>>  command = ('covoar -S ' + symbol_file
>>>+ ' -O ' + covoar_result_dir
>>>+ ' -E ' + self.explanations_txt
>>> diff --git a/tester/rt/test.py b/tester/rt/test.py
>>> index 0e744cd..cdb5157 100644
>>> --- a/tester/rt/test.py
>>> +++ b/tester/rt/test.py
>>> @@ -232,7 +232,7 @@ def run(command_path = None):
>>>  '--filter': 'Glob that executables must
>>> match to run (default: ' +
>>>default_exefilter + ')',
>>>  '--stacktrace': 'Dump a stack trace on a user
>>> termination (^C)',
>>> -'--coverage':   'Perform coverage analysis of
>>> test executables.'}
>>> +'--coverage-sets':  'Perform coverage for specific
>>> sets'}
>>>  mailer.append_options(optargs)
>>>  opts = options.load(sys.argv,
>>>  optargs = optargs,
>>> @@ -279,15 +279,20 @@ def run(command_path = None):
>>>  else:
>>>  rtems_tools = '%{_prefix}'
>>>  bsp = opts.find_arg('--rtems-bsp')
>>> +if 'cov' in bsp[1].split('-'):
>>> +coverage_enabled = True
>>>  if bsp is None or len(bsp) != 2:
>>>  raise error.general('RTEMS BSP not provided or an invalid
>>> option')
>>>  bsp = config.load(bsp[1], opts)
>>>  bsp_config = opts.defaults.expand(opts.defaults['tester'])
>>> -coverage_enabled = opts.find_arg('--coverage')
>>> +coverage_sets = opts.find_arg('--coverage-sets')
>>>  if coverage_enabled:
>>> -if len(coverage_enabled) == 2:
>>> -coverage_runner = coverage.coverage_run(opts.defaults,
>>> -coverage_enabled[1],
>>> +if coverage_sets:
>>> +if len(coverage_sets) != 2:
>>> +raise error.general('No sets provided in
>>> --coverage-sets')
>>> +else :
>>> +coverage_runner =
>>> coverage.coverage_run(opts.defaults,
>>> +coverage_sets[1],
>>>  executables)
>>>  else:
>>>  coverage_runner = coverage.coverage_run(opts.defaults,
>>> 0,
>>> --
>>> 2.14.3
>>>
>>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

Please review this patch. :)
On 7 June 2018 at 16:38, Vijay Kumar Banerjee 
wrote:

> Close #3440
> ---
>  tester/rt/coverage.py |  6 --
>  tester/rt/test.py | 15 ++-
>  2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> index 54933d5..af24124 100644
> --- a/tester/rt/coverage.py
> +++ b/tester/rt/coverage.py
> @@ -163,7 +163,8 @@ class report_gen_html:
>  row += " " + summary.branches_uncovered + ""
>  row += " " + summary.branches_total + ""
>  row += "  {:.3%} ".format(summary.
> percentage_branches_covered)
> -row += '  max="100">'.format(100*summary.percentage_
> branches_covered)
> +row += '  max="100">'\
> +.format(100*summary.percentage_branches_covered)
>  row += "\n"
>  return row
>
> @@ -299,7 +300,8 @@ class covoar(object):
>  if (not path.exists(covoar_result_dir)):
>  path.mkdir(covoar_result_dir)
>  if (not path.exists(symbol_file)):
> -raise error.general('symbol set file: coverage %s was not
> created for covoar, skipping %s'% (symbol_file, set_name))
> +raise error.general('symbol set file: %s was not '
> +'created for covoar, skipping %s'% (symbol_file,
> set_name))
>  command = ('covoar -S ' + symbol_file
>+ ' -O ' + covoar_result_dir
>+ ' -E ' + self.explanations_txt
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 0e744cd..cdb5157 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -232,7 +232,7 @@ def run(command_path = None):
>  '--filter': 'Glob that executables must match
> to run (default: ' +
>default_exefilter + ')',
>  '--stacktrace': 'Dump a stack trace on a user
> termination (^C)',
> -'--coverage':   'Perform coverage analysis of
> test executables.'}
> +'--coverage-sets':  'Perform coverage for specific
> sets'}
>  mailer.append_options(optargs)
>  opts = options.load(sys.argv,
>  optargs = optargs,
> @@ -279,15 +279,20 @@ def run(command_path = None):
>  else:
>  rtems_tools = '%{_prefix}'
>  bsp = opts.find_arg('--rtems-bsp')
> +if 'cov' in bsp[1].split('-'):
> +coverage_enabled = True
>  if bsp is None or len(bsp) != 2:
>  raise error.general('RTEMS BSP not provided or an invalid
> option')
>  bsp = config.load(bsp[1], opts)
>  bsp_config = opts.defaults.expand(opts.defaults['tester'])
> -coverage_enabled = opts.find_arg('--coverage')
> +coverage_sets = opts.find_arg('--coverage-sets')
>  if coverage_enabled:
> -if len(coverage_enabled) == 2:
> -coverage_runner = coverage.coverage_run(opts.defaults,
> -coverage_enabled[1],
> +if coverage_sets:
> +if len(coverage_sets) != 2:
> +raise error.general('No sets provided in
> --coverage-sets')
> +else :
> +coverage_runner = coverage.coverage_run(opts.
> defaults,
> +coverage_sets[1],
>  executables)
>  else:
>  coverage_runner = coverage.coverage_run(opts.defaults, 0,
> --
> 2.14.3
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 6 June 2018 at 20:49, Joel Sherrill  wrote:

> I can't duplicate this. My configure command was:
>
> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
> --prefix=/home/joel/rtems-work/tools/5 \
>--disable-networking --enable-posix --disable-smp
> --disable-multiprocessing \
>--enable-tests --enable-cxx --enable-maintainer-mode
>
> What was yours?
>
>
> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I have added the following changes in the bsps/sparc/leon3/config/leon3.
>> cfg
>>
>> --
>> CFLAGS_OPTIMIZE_V = -Os -g
>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>> ---
>>
>> While trying to build with these flags, I got a bunch of
>> the following errors:
>>
>> ==
>> {standard input}: Assembler messages:
>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>
>> ===
>>
>> after the `make install` I do get a lot of .gcno files, and no
>> executables.
>>
>> I am again getting these errors. Sometimes it builds just fine and
sometimes
I get these errors with the exact same steps.

here's the command I'm using to build leon3

../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3 \
--prefix=/home/lunatic/development/rtems/5 --disable-networking \
--enable-posix --disable-smp --disable-multiprocessing --enable-tests \
--enable-cxx --enable-maintainer-mode

please have a look at the full error in this gist.

https://gist.github.com/thelunatic/12f3091505afe7a79dcd74c106e1a10f
<https://gist.github.com/thelunatic/12f3091505afe7a79dcd74c106e1a10f>

-- vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Sun, 10 Jun 2018, 20:52 Joel Sherrill,  wrote:

>
>
> On Sat, Jun 9, 2018, 6:02 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 10 June 2018 at 04:16, Joel Sherrill  wrote:
>>
>>> I suggest this because it is a work around for you. The long term
>>> solution could be to add the symbol to newlib's dummy RTEMS crt0.c, add it
>>> to librtemscpu.a (which is the temporary hack I suggested), add a libgcov.a
>>> implementation or stub to RTEMS, or modify GCC.
>>>
>>> Up until now, we have avoided gcc options which altered the code under
>>> test. Test as you fly, fly as you test. This hints at a problem we need to
>>> think through. Is the call actually needed? I don't know.
>>>
>>> (according to my understanding)
>> To generate the gcov reports we would need it .
>> the -ftest-coverage generates a gcno file that contains information
>> about each branch in the code.
>> a code compiled with -fprofile-arcs includes libgcov which
>> gets invoked during the program exit. The coverage information is
>> collected during runtime and dumped into gcda file by libgcov.
>>
>
> We don't need it to gather its own information. Covoar generates it based
> on the execution trace. If all this option does is instrument the generated
> code and write results on exit, then we want to turn that off and teach
> covoar to write the same files.
>
Yes that's all the option does.
Understood. I'll try to figure out how the
gcov code in covoar works/is supposed
to work.

>
> On Sat, Jun 9, 2018, 5:38 PM Joel Sherrill  wrote:
>>>
>>>> For now, add a file to libcsupport/src which provides the symbols
>>>> needed. Make sure things are methods or data as needed. Check GCC source
>>>> for the prototype.
>>>>
>>>> This looks like something that is going to need a lot of reading.
>>
>>> On Sat, Jun 9, 2018, 3:34 PM Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 10 June 2018 at 01:28, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 10 June 2018 at 00:55, Joel Sherrill  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 9 June 2018 at 19:56, Joel Sherrill  wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
>>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> I was going through the gcc manual for gcov
>>>>>>>>>>>
>>>>>>>>>>> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization
>>>>>>>>>>>
>>>>>>>>>>> It mentions that the flag -fprofile-arcs is necessary for
>>>>>>>>>>> generating the .gcda files.
>>>>>>>>>>> I have tried it with a small hello world program to see the
>>>>>>>>>>> reports, and it seems
>>>>>>>>>>> that for .gcda files this flag is necessary.
>>>>>>>>>>>
>>>>>>>>>>> when I include the flag `-fprofile-arcs` with `-ftest-coverage`
>>>>>>>>>>> and then make
>>>>>>>>>>> I'm getting the following error.
>>>>>>>>>>>
>>>>>>>>>>> =
>>>>>>>>>>> checking whether the C compiler works... no
>>>>>>>>>>> configure: error: in
>>>>>>>>>>> `/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3':
>>>>>>>>>>> configure: error: C compiler cannot create executables
>>>>>>>>>>> See `config.log' for more details
&g

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 10 June 2018 at 01:28, Joel Sherrill  wrote:

>
>
> On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 10 June 2018 at 00:55, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 9 June 2018 at 19:56, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I was going through the gcc manual for gcov
>>>>>> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-
>>>>>> Optimization.html#Gcov-and-Optimization
>>>>>>
>>>>>> It mentions that the flag -fprofile-arcs is necessary for generating
>>>>>> the .gcda files.
>>>>>> I have tried it with a small hello world program to see the reports,
>>>>>> and it seems
>>>>>> that for .gcda files this flag is necessary.
>>>>>>
>>>>>> when I include the flag `-fprofile-arcs` with `-ftest-coverage` and
>>>>>> then make
>>>>>> I'm getting the following error.
>>>>>>
>>>>>> =
>>>>>> checking whether the C compiler works... no
>>>>>> configure: error: in `/home/lunatic/development/
>>>>>> rtems/kernel/leon3/sparc-rtems5/c/leon3':
>>>>>> configure: error: C compiler cannot create executables
>>>>>> See `config.log' for more details
>>>>>> gmake[2]: *** [Makefile:731: leon3] Error 1
>>>>>> gmake[2]: Leaving directory '/home/lunatic/development/
>>>>>> rtems/kernel/leon3/sparc-rtems5/c'
>>>>>> gmake[1]: *** [Makefile:289: all-recursive] Error 1
>>>>>> gmake[1]: Leaving directory '/home/lunatic/development/
>>>>>> rtems/kernel/leon3/sparc-rtems5/c'
>>>>>> gmake: *** [Makefile:414: all-recursive] Error 1
>>>>>>
>>>>>> =
>>>>>>
>>>>>
>>>>> It may be looking for a symbol provided by libgov.a. We don't have
>>>>> that based on how we do coverage.
>>>>>
>>>>> The normal approach is to add it to the RTEMS dummy crt0.c in newlib.
>>>>>
>>>>
>>>> er looks confusing, are there any instructions ? :)
>>>>
>>>
>>> What's the error first? What was in config.log in the directory with the
>>> failure?
>>>
>>> I added this.
>>
>> CFLAGS_OPTIMIZE_V += -fprofile-arcs -ftest-coverage
>>
>> when I `make` it, I see this error.
>>
>> =
>> checking whether the C compiler works... no
>> configure: error: in `/home/lunatic/development/rtems/kernel/leon3/sparc-
>> rtems5/c/leon3':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> gmake[2]: *** [Makefile:731: leon3] Error 1
>> gmake[2]: Leaving directory '/home/lunatic/development/
>> rtems/kernel/leon3/sparc-rtems5/c'
>> gmake[1]: *** [Makefile:289: all-recursive] Error 1
>> gmake[1]: Leaving directory '/home/lunatic/development/
>> rtems/kernel/leon3/sparc-rtems5/c'
>> gmake: *** [Makefile:414: all-recursive] Error 1
>>
>> =
>>
>
> I completely understood that. When you look in config.log in what looks to
> be a leon3 subdirectory, what's in the log file?
>
> I have attached the config.log file .


> My reading of the gcc manual was that one of those options implicitly
> added an option to link with libgcov.a. please confirm that.
>
yes , -fprofile-arcs implicitly adds option to link with libgcov

>
>>
>>
>>>
>>>
>>>>>>
>>>>>> On 8 June 2018 at 01:13, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 8 Jun 2018, 01:09 Joel Sherrill,  wrote:
>>>>>>>
>>>>>>>> Bringing in Krzysztof. Hoping he can get us on the right track here.
>>>>>>>>
>>>>>>>> I don't think you can run GcovData.

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 10 June 2018 at 00:55, Joel Sherrill  wrote:

>
>
> On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 9 June 2018 at 19:56, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I was going through the gcc manual for gcov
>>>> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-
>>>> Optimization
>>>>
>>>> It mentions that the flag -fprofile-arcs is necessary for generating
>>>> the .gcda files.
>>>> I have tried it with a small hello world program to see the reports,
>>>> and it seems
>>>> that for .gcda files this flag is necessary.
>>>>
>>>> when I include the flag `-fprofile-arcs` with `-ftest-coverage` and
>>>> then make
>>>> I'm getting the following error.
>>>>
>>>> =
>>>> checking whether the C compiler works... no
>>>> configure: error: in `/home/lunatic/development/
>>>> rtems/kernel/leon3/sparc-rtems5/c/leon3':
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details
>>>> gmake[2]: *** [Makefile:731: leon3] Error 1
>>>> gmake[2]: Leaving directory '/home/lunatic/development/
>>>> rtems/kernel/leon3/sparc-rtems5/c'
>>>> gmake[1]: *** [Makefile:289: all-recursive] Error 1
>>>> gmake[1]: Leaving directory '/home/lunatic/development/
>>>> rtems/kernel/leon3/sparc-rtems5/c'
>>>> gmake: *** [Makefile:414: all-recursive] Error 1
>>>>
>>>> =
>>>>
>>>
>>> It may be looking for a symbol provided by libgov.a. We don't have that
>>> based on how we do coverage.
>>>
>>> The normal approach is to add it to the RTEMS dummy crt0.c in newlib.
>>>
>>
>> er looks confusing, are there any instructions ? :)
>>
>
> What's the error first? What was in config.log in the directory with the
> failure?
>
> I added this.

CFLAGS_OPTIMIZE_V += -fprofile-arcs -ftest-coverage

when I `make` it, I see this error.

=
checking whether the C compiler works... no
configure: error: in `/home/lunatic/development/rtems/kernel/leon3/sparc-
rtems5/c/leon3':
configure: error: C compiler cannot create executables
See `config.log' for more details
gmake[2]: *** [Makefile:731: leon3] Error 1
gmake[2]: Leaving directory '/home/lunatic/development/
rtems/kernel/leon3/sparc-rtems5/c'
gmake[1]: *** [Makefile:289: all-recursive] Error 1
gmake[1]: Leaving directory '/home/lunatic/development/
rtems/kernel/leon3/sparc-rtems5/c'
gmake: *** [Makefile:414: all-recursive] Error 1

=====



>
>
>>>>
>>>> On 8 June 2018 at 01:13, Vijay Kumar Banerjee >>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 8 Jun 2018, 01:09 Joel Sherrill,  wrote:
>>>>>
>>>>>> Bringing in Krzysztof. Hoping he can get us on the right track here.
>>>>>>
>>>>>> I don't think you can run GcovData.cc independent of a covoar run.
>>>>>>
>>>>> Understood.
>>>>>
>>>>>> If you can figure out how to write a unit test that would be helpful.
>>>>>>
>>>>> Will try to do that if possible.
>>>>>
>>>>>>
>>>>>> On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I was looking into the code in GcovData.cc to see how it works
>>>>>>> and what it's doing, too me it looked like very messed up, I couldn't
>>>>>>> understand (yet) what it's trying to do.
>>>>>>> Is there some way I can manually run it for one file?
>>>>>>> Is there any place where I can read how it was intended to work?
>>>>>>> Or something like a flow diagram?
>>>>>>>
>>>>>>>
>>>>>>> -- vijay
>>>>>>>
>>>>>>> On 7 June 2018 at 02:56, Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 9 June 2018 at 19:56, Joel Sherrill  wrote:

>
>
> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I was going through the gcc manual for gcov
>> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-
>> Optimization
>>
>> It mentions that the flag -fprofile-arcs is necessary for generating the
>> .gcda files.
>> I have tried it with a small hello world program to see the reports, and
>> it seems
>> that for .gcda files this flag is necessary.
>>
>> when I include the flag `-fprofile-arcs` with `-ftest-coverage` and then
>> make
>> I'm getting the following error.
>>
>> =
>> checking whether the C compiler works... no
>> configure: error: in `/home/lunatic/development/rtems/kernel/leon3/sparc-
>> rtems5/c/leon3':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details
>> gmake[2]: *** [Makefile:731: leon3] Error 1
>> gmake[2]: Leaving directory '/home/lunatic/development/
>> rtems/kernel/leon3/sparc-rtems5/c'
>> gmake[1]: *** [Makefile:289: all-recursive] Error 1
>> gmake[1]: Leaving directory '/home/lunatic/development/
>> rtems/kernel/leon3/sparc-rtems5/c'
>> gmake: *** [Makefile:414: all-recursive] Error 1
>>
>> =
>>
>
> It may be looking for a symbol provided by libgov.a. We don't have that
> based on how we do coverage.
>
> The normal approach is to add it to the RTEMS dummy crt0.c in newlib.
>

er looks confusing, are there any instructions ? :)

>
>>
>> On 8 June 2018 at 01:13, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Fri, 8 Jun 2018, 01:09 Joel Sherrill,  wrote:
>>>
>>>> Bringing in Krzysztof. Hoping he can get us on the right track here.
>>>>
>>>> I don't think you can run GcovData.cc independent of a covoar run.
>>>>
>>> Understood.
>>>
>>>> If you can figure out how to write a unit test that would be helpful.
>>>>
>>> Will try to do that if possible.
>>>
>>>>
>>>> On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I was looking into the code in GcovData.cc to see how it works
>>>>> and what it's doing, too me it looked like very messed up, I couldn't
>>>>> understand (yet) what it's trying to do.
>>>>> Is there some way I can manually run it for one file?
>>>>> Is there any place where I can read how it was intended to work?
>>>>> Or something like a flow diagram?
>>>>>
>>>>>
>>>>> -- vijay
>>>>>
>>>>> On 7 June 2018 at 02:56, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>>>>>>>>
>>>>>>>>>>> I can't duplicate this. My configure command was:
>>>>>>>>>>>
>>>>>>>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>>>>>>>>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>>>>>>>>>--disable-networking --enable-posix --disable-smp
>>>>>>>>>>> --disable-multiprocessing \
>>>>>>>>>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>>>>>>>>>
>>>>>>>>>>> What was yours?
>>>>>>>>>>>
>>>>>>>>>>

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

Hello,

I was going through the gcc manual for gcov
https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization

It mentions that the flag -fprofile-arcs is necessary for generating the
.gcda files.
I have tried it with a small hello world program to see the reports, and it
seems
that for .gcda files this flag is necessary.

when I include the flag `-fprofile-arcs` with `-ftest-coverage` and then
make
I'm getting the following error.

=
checking whether the C compiler works... no
configure: error: in
`/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3':
configure: error: C compiler cannot create executables
See `config.log' for more details
gmake[2]: *** [Makefile:731: leon3] Error 1
gmake[2]: Leaving directory
'/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c'
gmake[1]: *** [Makefile:289: all-recursive] Error 1
gmake[1]: Leaving directory
'/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c'
gmake: *** [Makefile:414: all-recursive] Error 1

=


On 8 June 2018 at 01:13, Vijay Kumar Banerjee 
wrote:

>
>
> On Fri, 8 Jun 2018, 01:09 Joel Sherrill,  wrote:
>
>> Bringing in Krzysztof. Hoping he can get us on the right track here.
>>
>> I don't think you can run GcovData.cc independent of a covoar run.
>>
> Understood.
>
>> If you can figure out how to write a unit test that would be helpful.
>>
> Will try to do that if possible.
>
>>
>> On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I was looking into the code in GcovData.cc to see how it works
>>> and what it's doing, too me it looked like very messed up, I couldn't
>>> understand (yet) what it's trying to do.
>>> Is there some way I can manually run it for one file?
>>> Is there any place where I can read how it was intended to work?
>>> Or something like a flow diagram?
>>>
>>>
>>> -- vijay
>>>
>>> On 7 June 2018 at 02:56, Vijay Kumar Banerjee 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>>>>>>
>>>>>>>>> I can't duplicate this. My configure command was:
>>>>>>>>>
>>>>>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>>>>>>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>>>>>>>--disable-networking --enable-posix --disable-smp
>>>>>>>>> --disable-multiprocessing \
>>>>>>>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>>>>>>>
>>>>>>>>> What was yours?
>>>>>>>>>
>>>>>>>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>>>>>>>
>>>>>>>> I made some tries and somehow it's perfectly working now.
>>>>>>>>
>>>>>>>> I am trying to find out now how covoar generates the reports.
>>>>>>>> I made a file with a list of all gcno in score/ and run with -g
>>>>>>>> argument
>>>>>>>> now I'mg seeing the following error while running covoar
>>>>>>>>
>>>>>>>> ==
>>>>>>>> Generating Gcov reports...
>>>>>>>> Processing file: libscore_a-allocatormutex.gcno
>>>>>>>> Unable to open libscore_a-allocatormutex.gcno
>>>>>>>> Processing file: libscore_a-apimutexisowner.gcno
>>>>>>>> Unable to open libscore_a-apimutexisowner.gcno
>>>>>>>> Processing file: libscore_a-apimutexlock.gcno
>>>>>>>> Unable to open libscore_a-apimutexlock.gcno
>>>>>>>> Processing file: libscore_a-apimutexunlock.gcno
>>>>>&

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Fri, 8 Jun 2018, 01:09 Joel Sherrill,  wrote:

> Bringing in Krzysztof. Hoping he can get us on the right track here.
>
> I don't think you can run GcovData.cc independent of a covoar run.
>
Understood.

> If you can figure out how to write a unit test that would be helpful.
>
Will try to do that if possible.

>
> On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I was looking into the code in GcovData.cc to see how it works
>> and what it's doing, too me it looked like very messed up, I couldn't
>> understand (yet) what it's trying to do.
>> Is there some way I can manually run it for one file?
>> Is there any place where I can read how it was intended to work?
>> Or something like a flow diagram?
>>
>>
>> -- vijay
>>
>> On 7 June 2018 at 02:56, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>>>>>
>>>>>>>> I can't duplicate this. My configure command was:
>>>>>>>>
>>>>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>>>>>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>>>>>>--disable-networking --enable-posix --disable-smp
>>>>>>>> --disable-multiprocessing \
>>>>>>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>>>>>>
>>>>>>>> What was yours?
>>>>>>>>
>>>>>>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>>>>>>
>>>>>>> I made some tries and somehow it's perfectly working now.
>>>>>>>
>>>>>>> I am trying to find out now how covoar generates the reports.
>>>>>>> I made a file with a list of all gcno in score/ and run with -g
>>>>>>> argument
>>>>>>> now I'mg seeing the following error while running covoar
>>>>>>>
>>>>>>> ==
>>>>>>> Generating Gcov reports...
>>>>>>> Processing file: libscore_a-allocatormutex.gcno
>>>>>>> Unable to open libscore_a-allocatormutex.gcno
>>>>>>> Processing file: libscore_a-apimutexisowner.gcno
>>>>>>> Unable to open libscore_a-apimutexisowner.gcno
>>>>>>> Processing file: libscore_a-apimutexlock.gcno
>>>>>>> Unable to open libscore_a-apimutexlock.gcno
>>>>>>> Processing file: libscore_a-apimutexunlock.gcno
>>>>>>> Unable to open libscore_a-apimutexunlock.gcno
>>>>>>> Processing file: libscore_a-chain.gcno
>>>>>>> Unable to open libscore_a-chain.gcno
>>>>>>> Processing file: libscore_a-chainnodecount.gcno
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> ==
>>>>>>>
>>>>>>
>>>>>> I suspect this is another instance of the path issues inside the
>>>>>> build tree you and Cillian fixed earlier.
>>>>>>
>>>>>> correcting the path worked.
>>>>>
>>>>
>>>> Submit a patch for this. It needs fixing to get 5onyour next issue.
>>>>
>>> It just needed the absolute path to be fed.
>>> here's what I did.
>>> I manually 'find' all the gcno files under score.
>>> wrote it all in a file separated by newlines.
>>> fed that file as an argument to covoar.
>>> and that brought me here.
>>>
>>> So when we write script, these are the
>>> things that will be done by the script.
>>>
>>> Once everything strats running manually,
>>> we can proceed to write scripts.
>>>
>>>>
>>>>> Now I'm getting this error.
>

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

Hello,

I was looking into the code in GcovData.cc to see how it works
and what it's doing, too me it looked like very messed up, I couldn't
understand (yet) what it's trying to do.
Is there some way I can manually run it for one file?
Is there any place where I can read how it was intended to work?
Or something like a flow diagram?


-- vijay

On 7 June 2018 at 02:56, Vijay Kumar Banerjee 
wrote:

>
>
> On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:
>
>>
>>
>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>>>
>>>>>> I can't duplicate this. My configure command was:
>>>>>>
>>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>>>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>>>>--disable-networking --enable-posix --disable-smp
>>>>>> --disable-multiprocessing \
>>>>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>>>>
>>>>>> What was yours?
>>>>>>
>>>>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>>>>
>>>>> I made some tries and somehow it's perfectly working now.
>>>>>
>>>>> I am trying to find out now how covoar generates the reports.
>>>>> I made a file with a list of all gcno in score/ and run with -g
>>>>> argument
>>>>> now I'mg seeing the following error while running covoar
>>>>>
>>>>> ==
>>>>> Generating Gcov reports...
>>>>> Processing file: libscore_a-allocatormutex.gcno
>>>>> Unable to open libscore_a-allocatormutex.gcno
>>>>> Processing file: libscore_a-apimutexisowner.gcno
>>>>> Unable to open libscore_a-apimutexisowner.gcno
>>>>> Processing file: libscore_a-apimutexlock.gcno
>>>>> Unable to open libscore_a-apimutexlock.gcno
>>>>> Processing file: libscore_a-apimutexunlock.gcno
>>>>> Unable to open libscore_a-apimutexunlock.gcno
>>>>> Processing file: libscore_a-chain.gcno
>>>>> Unable to open libscore_a-chain.gcno
>>>>> Processing file: libscore_a-chainnodecount.gcno
>>>>> .
>>>>> .
>>>>> .
>>>>> ==
>>>>>
>>>>
>>>> I suspect this is another instance of the path issues inside the build
>>>> tree you and Cillian fixed earlier.
>>>>
>>>> correcting the path worked.
>>>
>>
>> Submit a patch for this. It needs fixing to get 5onyour next issue.
>>
> It just needed the absolute path to be fed.
> here's what I did.
> I manually 'find' all the gcno files under score.
> wrote it all in a file separated by newlines.
> fed that file as an argument to covoar.
> and that brought me here.
>
> So when we write script, these are the
> things that will be done by the script.
>
> Once everything strats running manually,
> we can proceed to write scripts.
>
>>
>>> Now I'm getting this error.
>>>
>>> Generating Gcov reports...
>>> Processing file: sparc-rtems5/c/leon3/cpukit/
>>> score/src/libscore_a-kern_tc.gcno
>>> ERROR: Unable to read string from gcov file
>>> ERROR: Unable to read string length from gcov file
>>> ERROR: Unable to read Function starting line number
>>> Segmentation fault (core dumped)
>>>
>>
>> Welcome to GSoC! You are now in new territory. :)
>>
> So here the real work begins!
>
>>
>> Dig in and see what went wrong. Be aware.that GCC file formats may (or
>> may not) be subject to.changing over time and this could just be bitrot.
>>
> I got started with it.
>
>>
>> Gcov-dump is installed with the compiler.
>>
>> You should check it we have a .h file describing the file and it is out
>> of date.
>>
> I'll look into it.
>
>>
>> Also I think we now should bring the gsov maintainer in.
>>
> The covoar's gcov support needs to be reworked.
> We can get the help of the expert here.
>
>>
>> Good job!
>>
> Thanks. :)
>
>>
>>
>>>

[PATCH] coverage : Add support to run coverage in supported bsp without extra options

[Vijay Kumar Banerjee]

Close #3440
---
 tester/rt/coverage.py |  6 --
 tester/rt/test.py | 15 ++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
index 54933d5..af24124 100644
--- a/tester/rt/coverage.py
+++ b/tester/rt/coverage.py
@@ -163,7 +163,8 @@ class report_gen_html:
 row += " " + summary.branches_uncovered + ""
 row += " " + summary.branches_total + ""
 row += "  {:.3%} 
".format(summary.percentage_branches_covered)
-row += ' '.format(100*summary.percentage_branches_covered)
+row += ' '\
+.format(100*summary.percentage_branches_covered)
 row += "\n"
 return row
 
@@ -299,7 +300,8 @@ class covoar(object):
 if (not path.exists(covoar_result_dir)):
 path.mkdir(covoar_result_dir)
 if (not path.exists(symbol_file)):
-raise error.general('symbol set file: coverage %s was not created 
for covoar, skipping %s'% (symbol_file, set_name))
+raise error.general('symbol set file: %s was not '
+'created for covoar, skipping %s'% (symbol_file, set_name))
 command = ('covoar -S ' + symbol_file
   + ' -O ' + covoar_result_dir
   + ' -E ' + self.explanations_txt
diff --git a/tester/rt/test.py b/tester/rt/test.py
index 0e744cd..cdb5157 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -232,7 +232,7 @@ def run(command_path = None):
 '--filter': 'Glob that executables must match to 
run (default: ' +
   default_exefilter + ')',
 '--stacktrace': 'Dump a stack trace on a user 
termination (^C)',
-'--coverage':   'Perform coverage analysis of test 
executables.'}
+'--coverage-sets':  'Perform coverage for specific sets'}
 mailer.append_options(optargs)
 opts = options.load(sys.argv,
 optargs = optargs,
@@ -279,15 +279,20 @@ def run(command_path = None):
 else:
 rtems_tools = '%{_prefix}'
 bsp = opts.find_arg('--rtems-bsp')
+if 'cov' in bsp[1].split('-'):
+coverage_enabled = True
 if bsp is None or len(bsp) != 2:
 raise error.general('RTEMS BSP not provided or an invalid option')
 bsp = config.load(bsp[1], opts)
 bsp_config = opts.defaults.expand(opts.defaults['tester'])
-coverage_enabled = opts.find_arg('--coverage')
+coverage_sets = opts.find_arg('--coverage-sets')
 if coverage_enabled:
-if len(coverage_enabled) == 2:
-coverage_runner = coverage.coverage_run(opts.defaults,
-coverage_enabled[1],
+if coverage_sets:
+if len(coverage_sets) != 2:
+raise error.general('No sets provided in --coverage-sets')
+else :
+coverage_runner = coverage.coverage_run(opts.defaults,
+coverage_sets[1],
 executables)
 else:
 coverage_runner = coverage.coverage_run(opts.defaults, 0,
-- 
2.14.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Thu, 7 Jun 2018, 02:39 Joel Sherrill,  wrote:

>
>
> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 7 June 2018 at 01:48, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>>>
>>>>> I can't duplicate this. My configure command was:
>>>>>
>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>>>--disable-networking --enable-posix --disable-smp
>>>>> --disable-multiprocessing \
>>>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>>>
>>>>> What was yours?
>>>>>
>>>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>>>
>>>> I made some tries and somehow it's perfectly working now.
>>>>
>>>> I am trying to find out now how covoar generates the reports.
>>>> I made a file with a list of all gcno in score/ and run with -g argument
>>>> now I'mg seeing the following error while running covoar
>>>>
>>>> ==
>>>> Generating Gcov reports...
>>>> Processing file: libscore_a-allocatormutex.gcno
>>>> Unable to open libscore_a-allocatormutex.gcno
>>>> Processing file: libscore_a-apimutexisowner.gcno
>>>> Unable to open libscore_a-apimutexisowner.gcno
>>>> Processing file: libscore_a-apimutexlock.gcno
>>>> Unable to open libscore_a-apimutexlock.gcno
>>>> Processing file: libscore_a-apimutexunlock.gcno
>>>> Unable to open libscore_a-apimutexunlock.gcno
>>>> Processing file: libscore_a-chain.gcno
>>>> Unable to open libscore_a-chain.gcno
>>>> Processing file: libscore_a-chainnodecount.gcno
>>>> .
>>>> .
>>>> .
>>>> ==
>>>>
>>>
>>> I suspect this is another instance of the path issues inside the build
>>> tree you and Cillian fixed earlier.
>>>
>>> correcting the path worked.
>>
>
> Submit a patch for this. It needs fixing to get 5onyour next issue.
>
It just needed the absolute path to be fed.
here's what I did.
I manually 'find' all the gcno files under score.
wrote it all in a file separated by newlines.
fed that file as an argument to covoar.
and that brought me here.

So when we write script, these are the
things that will be done by the script.

Once everything strats running manually,
we can proceed to write scripts.

>
>> Now I'm getting this error.
>>
>> Generating Gcov reports...
>> Processing file:
>> sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno
>> ERROR: Unable to read string from gcov file
>> ERROR: Unable to read string length from gcov file
>> ERROR: Unable to read Function starting line number
>> Segmentation fault (core dumped)
>>
>
> Welcome to GSoC! You are now in new territory. :)
>
So here the real work begins!

>
> Dig in and see what went wrong. Be aware.that GCC file formats may (or may
> not) be subject to.changing over time and this could just be bitrot.
>
I got started with it.

>
> Gcov-dump is installed with the compiler.
>
> You should check it we have a .h file describing the file and it is out of
> date.
>
I'll look into it.

>
> Also I think we now should bring the gsov maintainer in.
>
The covoar's gcov support needs to be reworked.
We can get the help of the expert here.

>
> Good job!
>
Thanks. :)

>
>
>>
>>>>> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have added the following changes in the
>>>>>> bsps/sparc/leon3/config/leon3.cfg
>>>>>>
>>>>>> --
>>>>>> CFLAGS_OPTIMIZE_V = -Os -g
>>>>>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>>>>>> ---
>>>>>>
>>>>>> While trying to build with these flags, I got a bunch of
>>>>>> the following errors:
>>>>>>
>>>>>> ==
>>>>>> {standard input}: Assembler messages:
>>>>>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>>>>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>>>>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>>>>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>>>>>
>>>>>> ===
>>>>>>
>>>>>> after the `make install` I do get a lot of .gcno files, and no
>>>>>> executables.
>>>>>>
>>>>>> -- vijay
>>>>>>
>>>>>> ___
>>>>>> devel mailing list
>>>>>> devel@rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>
>>>>>
>>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 7 June 2018 at 01:48, Joel Sherrill  wrote:

>
>
> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 6 June 2018 at 20:49, Joel Sherrill  wrote:
>>
>>> I can't duplicate this. My configure command was:
>>>
>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
>>> --prefix=/home/joel/rtems-work/tools/5 \
>>>--disable-networking --enable-posix --disable-smp
>>> --disable-multiprocessing \
>>>--enable-tests --enable-cxx --enable-maintainer-mode
>>>
>>> What was yours?
>>>
>>> I didn't have --enable-cxx and --enable-maintainer-more.
>>
>> I made some tries and somehow it's perfectly working now.
>>
>> I am trying to find out now how covoar generates the reports.
>> I made a file with a list of all gcno in score/ and run with -g argument
>> now I'mg seeing the following error while running covoar
>>
>> ==
>> Generating Gcov reports...
>> Processing file: libscore_a-allocatormutex.gcno
>> Unable to open libscore_a-allocatormutex.gcno
>> Processing file: libscore_a-apimutexisowner.gcno
>> Unable to open libscore_a-apimutexisowner.gcno
>> Processing file: libscore_a-apimutexlock.gcno
>> Unable to open libscore_a-apimutexlock.gcno
>> Processing file: libscore_a-apimutexunlock.gcno
>> Unable to open libscore_a-apimutexunlock.gcno
>> Processing file: libscore_a-chain.gcno
>> Unable to open libscore_a-chain.gcno
>> Processing file: libscore_a-chainnodecount.gcno
>> .
>> .
>> .
>> ==
>>
>
> I suspect this is another instance of the path issues inside the build
> tree you and Cillian fixed earlier.
>
> correcting the path worked.

Now I'm getting this error.

Generating Gcov reports...
Processing file:
sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno
ERROR: Unable to read string from gcov file
ERROR: Unable to read string length from gcov file
ERROR: Unable to read Function starting line number
Segmentation fault (core dumped)


>>> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have added the following changes in the bsps/sparc/leon3/config/leon3.
>>>> cfg
>>>>
>>>> --
>>>> CFLAGS_OPTIMIZE_V = -Os -g
>>>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>>>> ---
>>>>
>>>> While trying to build with these flags, I got a bunch of
>>>> the following errors:
>>>>
>>>> ==
>>>> {standard input}: Assembler messages:
>>>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>>>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>>>
>>>> ===
>>>>
>>>> after the `make install` I do get a lot of .gcno files, and no
>>>> executables.
>>>>
>>>> -- vijay
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 6 June 2018 at 20:49, Joel Sherrill  wrote:

> I can't duplicate this. My configure command was:
>
> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3
> --prefix=/home/joel/rtems-work/tools/5 \
>--disable-networking --enable-posix --disable-smp
> --disable-multiprocessing \
>--enable-tests --enable-cxx --enable-maintainer-mode
>
> What was yours?
>
> I didn't have --enable-cxx and --enable-maintainer-more.

I made some tries and somehow it's perfectly working now.

I am trying to find out now how covoar generates the reports.
I made a file with a list of all gcno in score/ and run with -g argument
now I'mg seeing the following error while running covoar

==
Generating Gcov reports...
Processing file: libscore_a-allocatormutex.gcno
Unable to open libscore_a-allocatormutex.gcno
Processing file: libscore_a-apimutexisowner.gcno
Unable to open libscore_a-apimutexisowner.gcno
Processing file: libscore_a-apimutexlock.gcno
Unable to open libscore_a-apimutexlock.gcno
Processing file: libscore_a-apimutexunlock.gcno
Unable to open libscore_a-apimutexunlock.gcno
Processing file: libscore_a-chain.gcno
Unable to open libscore_a-chain.gcno
Processing file: libscore_a-chainnodecount.gcno
.
.
.
==

>
> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> I have added the following changes in the bsps/sparc/leon3/config/leon3.
>> cfg
>>
>> --
>> CFLAGS_OPTIMIZE_V = -Os -g
>> CFLAGS_OPTIMIZE_V += -ftest-coverage
>> ---
>>
>> While trying to build with these flags, I got a bunch of
>> the following errors:
>>
>> ==
>> {standard input}: Assembler messages:
>> {standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>> {standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
>> {.data._SPARC_Counter section} - `.LLtext0' {.text section}
>>
>> ===
>>
>> after the `make install` I do get a lot of .gcno files, and no
>> executables.
>>
>> -- vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

Hello,

I have added the following changes in the bsps/sparc/leon3/config/leon3.cfg

--
CFLAGS_OPTIMIZE_V = -Os -g
CFLAGS_OPTIMIZE_V += -ftest-coverage
---

While trying to build with these flags, I got a bunch of
the following errors:

==
{standard input}: Assembler messages:
{standard input}:6510: Error: can't resolve `.data._SPARC_Counter'
{.data._SPARC_Counter section} - `.LLtext0' {.text section}
{standard input}:6511: Error: can't resolve `.data._SPARC_Counter'
{.data._SPARC_Counter section} - `.LLtext0' {.text section}

===

after the `make install` I do get a lot of .gcno files, and no
executables.

-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 6 June 2018 at 17:48, Joel Sherrill  wrote:

>
>
> On Wed, Jun 6, 2018, 1:16 AM Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Wed, 6 Jun 2018, 01:52 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>>>>
>>>>> I think everything is pushed. Is there any patch outstanding?
>>>>>
>>>>
>>>>> Thank you.
>>>> No outstanding patch, everything on my side is squashed into it. :)
>>>>
>>>
>>> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>>>
>>
>> That's everything! Started summer 2014 and now it's all merged, it's
>> great to see. Well done Vijay.
>>
>
> Thank you! Thanks to all the mentors for all the support and guidance. :)

> Agreed! Now to finish this GSoC's goals and define the near term things to
> work on.
>
> I have started filing the tickets.

P.S: It's great to be a part of such a wonderful community. :)

>
>>> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> Add support in tester to run covoar and generate an html report to
>>>>>> display
>>>>>> the summary of the coverage reports generated from covoar.
>>>>>>
>>>>>> Co-authored-by : Cillian O'Donnell 
>>>>>> ---
>>>>>>  .gitignore|   1 +
>>>>>>  tester/rt/coverage.py | 385
>>>>>> ++
>>>>>>  tester/rt/test.py |  34 ++-
>>>>>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>>>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>>>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>>>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>>>>>  create mode 100644 tester/rt/coverage.py
>>>>>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>
>>>>>> diff --git a/.gitignore b/.gitignore
>>>>>> index 6ab3709..93cb5d2 100644
>>>>>> --- a/.gitignore
>>>>>> +++ b/.gitignore
>>>>>> @@ -9,3 +9,4 @@ waf3-*
>>>>>>  .lock-waf*
>>>>>>  build
>>>>>>  VERSION*
>>>>>> +*symbols.ini
>>>>>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>>>>> new file mode 100644
>>>>>> index 000..54933d5
>>>>>> --- /dev/null
>>>>>> +++ b/tester/rt/coverage.py
>>>>>> @@ -0,0 +1,385 @@
>>>>>> +#
>>>>>> +# RTEMS Tools Project (http://www.rtems.org/)
>>>>>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>>>>>> +# All rights reserved.
>>>>>> +#
>>>>>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>>> +#
>>>>>> +# Redistribution and use in source and binary forms, with or without
>>>>>> +# modification, are permitted provided that the following conditions
>>>>>> are met:
>>>>>> +#
>>>>>> +# 1. Redistributions of source code must retain the above copyright
>>>>>> notice,
>>>>>> +# this list of conditions and the following disclaimer.
>>>>>> +#
>>>>>> +# 2. Redistributions in binary form must reproduce the above
>>>>>> copyright notice,
>>>>>> +# this list of conditions and the following disclaimer in the
>>>>>> documentation
>>>>>> +# and/or other materials provided with the distribution.
>>>>>> +#
>>>>>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>>>>>> CONTRIBUTORS 'AS IS'
>>>>>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>>>>>> TO, THE
>>>>>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>>>>> PURPOSE
>>>>>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>>>>>> CONTRIBUTO

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On Wed, 6 Jun 2018, 08:31 Joel Sherrill,  wrote:

>
>
> On Tue, Jun 5, 2018, 9:54 PM Chris Johns  wrote:
>
>>
>> On 31/5/18 6:44 am, Vijay Kumar Banerjee wrote:
>> > On 31 May 2018 at 02:02, Joel Sherrill > j...@rtems.org>>
>> > wrote:
>> > On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee
>> > mailto:vijaykumar9...@gmail.com>> wrote:
>> >
>> > On 31 May 2018 at 00:28, Joel Sherrill > > <mailto:j...@rtems.org>> wrote:
>> > I may not understand correctly but there is test_run and
>> > coverage_run. Someone
>> > suggested making coverage_running an option to test_run. If
>> that's
>> > what's being
>> > asked for, then I think doing it in a follow up patch is OK.
>> >
>> > If that's the intended request, perhaps a ticket should be
>> filed.
>> >
>> >
>> > Sorry for all the confusion.
>> > This patch doesn't change the way test works. It only adds an
>> option to run
>> > the coverage script. coverage_run just runs the
>> coverage.coverage_run
>> >
>> >
>> > :) And I am saying if we want to have one test_run with an
>> argument, do it as
>> > a future work iteration. File a ticket.
>> >
>> > We need to get the code working on the master.
>> >
>> > Okay, we can keep that as a future work (I haven't thought about it
>> though). :)
>> > Getting it to work on master is our primary objective.
>> >
>>
>> Was a ticket raised to removing 'coverage_run' and to use 'test_run'?
>>
>
> I haven't seen tickets for any of the issues we identified.
>
was there supposed to be tickets for each issue?

>
>> Chris
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On Wed, 6 Jun 2018, 06:22 Joel Sherrill,  wrote:

>
>
> On Tue, Jun 5, 2018, 7:22 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 6 June 2018 at 03:57, Joel Sherrill  wrote:
>>
>>> I think everything is pushed. Is there any patch outstanding?
>>>
>>
>>> Thank you.
>> No outstanding patch, everything on my side is squashed into it. :)
>>
>
> So we can (finally) switch to the RTEMS.org repos to as the baseline?
>
Yes, finally!

>
> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Add support in tester to run covoar and generate an html report to
>>>> display
>>>> the summary of the coverage reports generated from covoar.
>>>>
>>>> Co-authored-by : Cillian O'Donnell 
>>>> ---
>>>>  .gitignore|   1 +
>>>>  tester/rt/coverage.py | 385
>>>> ++
>>>>  tester/rt/test.py |  34 ++-
>>>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>>>  create mode 100644 tester/rt/coverage.py
>>>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>>
>>>> diff --git a/.gitignore b/.gitignore
>>>> index 6ab3709..93cb5d2 100644
>>>> --- a/.gitignore
>>>> +++ b/.gitignore
>>>> @@ -9,3 +9,4 @@ waf3-*
>>>>  .lock-waf*
>>>>  build
>>>>  VERSION*
>>>> +*symbols.ini
>>>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>>> new file mode 100644
>>>> index 000..54933d5
>>>> --- /dev/null
>>>> +++ b/tester/rt/coverage.py
>>>> @@ -0,0 +1,385 @@
>>>> +#
>>>> +# RTEMS Tools Project (http://www.rtems.org/)
>>>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>>>> +# All rights reserved.
>>>> +#
>>>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>> +#
>>>> +# Redistribution and use in source and binary forms, with or without
>>>> +# modification, are permitted provided that the following conditions
>>>> are met:
>>>> +#
>>>> +# 1. Redistributions of source code must retain the above copyright
>>>> notice,
>>>> +# this list of conditions and the following disclaimer.
>>>> +#
>>>> +# 2. Redistributions in binary form must reproduce the above copyright
>>>> notice,
>>>> +# this list of conditions and the following disclaimer in the
>>>> documentation
>>>> +# and/or other materials provided with the distribution.
>>>> +#
>>>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>>> 'AS IS'
>>>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>>>> TO, THE
>>>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>>> PURPOSE
>>>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>>>> CONTRIBUTORS BE
>>>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>>>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>>>> BUSINESS
>>>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>>>> IN
>>>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>>>> OTHERWISE)
>>>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
>>>> OF THE
>>>> +# POSSIBILITY OF SUCH DAMAGE.
>>>> +#
>>>> +
>>>> +from rtemstoolkit import error
>>>> +from rtemstoolkit import path
>>>> +from rtemstoolkit import log
>>>> +from rtemstoolkit import execute
>>>> +from rtemstoolkit import macros
>>>> +
>>>> +from datetime import datetime
>>>> +
>>>> +from . import options
>>>> +
>>>> +import shutil
>>>> +import os
>>>> +
>>>> +try:
>>>> +impo

Re: [PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 6 June 2018 at 03:57, Joel Sherrill  wrote:

> I think everything is pushed. Is there any patch outstanding?
>
> Thank you.
No outstanding patch, everything on my side is squashed into it. :)

> On Mon, Jun 4, 2018 at 3:44 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Add support in tester to run covoar and generate an html report to display
>> the summary of the coverage reports generated from covoar.
>>
>> Co-authored-by : Cillian O'Donnell 
>> ---
>>  .gitignore|   1 +
>>  tester/rt/coverage.py | 385
>> ++
>>  tester/rt/test.py |  34 ++-
>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>  tester/rtems/testing/qemu.cfg |   4 +-
>>  6 files changed, 450 insertions(+), 13 deletions(-)
>>  create mode 100644 tester/rt/coverage.py
>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>
>> diff --git a/.gitignore b/.gitignore
>> index 6ab3709..93cb5d2 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -9,3 +9,4 @@ waf3-*
>>  .lock-waf*
>>  build
>>  VERSION*
>> +*symbols.ini
>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> new file mode 100644
>> index 000..54933d5
>> --- /dev/null
>> +++ b/tester/rt/coverage.py
>> @@ -0,0 +1,385 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions are
>> met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> 'AS IS'
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>> THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>> BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +from rtemstoolkit import error
>> +from rtemstoolkit import path
>> +from rtemstoolkit import log
>> +from rtemstoolkit import execute
>> +from rtemstoolkit import macros
>> +
>> +from datetime import datetime
>> +
>> +from . import options
>> +
>> +import shutil
>> +import os
>> +
>> +try:
>> +import configparser
>> +except:
>> +import ConfigParser as configparser
>> +
>> +class summary:
>> +def __init__(self, p_summary_dir):
>> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
>> +self.bytes_analyzed = 0
>> +self.bytes_not_executed = 0
>> +self.percentage_executed = 0.0
>> +self.percentage_not_executed = 100.0
>> +self.ranges_uncovered = 0
>> +self.branches_uncovered = 0
>> +self.branches_total = 0
>> +self.branches_always_taken = 0
>> +self.branches_never_taken = 0
>> +self.percentage_branches_covered = 0.0
>> +self.is_failure = False
>> +
>> +def parse(self):
>> +if(not path.exists(self.summary_file_path)):
>> +log.notice('summary file %s does not exist!' %
>> (self.summary_file_path))
>> +self.is_failure

[PATCH v3] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

Add support in tester to run covoar and generate an html report to display
the summary of the coverage reports generated from covoar.

Co-authored-by : Cillian O'Donnell 
---
 .gitignore|   1 +
 tester/rt/coverage.py | 385 ++
 tester/rt/test.py |  34 ++-
 tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
 tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
 tester/rtems/testing/qemu.cfg |   4 +-
 6 files changed, 450 insertions(+), 13 deletions(-)
 create mode 100644 tester/rt/coverage.py
 create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini

diff --git a/.gitignore b/.gitignore
index 6ab3709..93cb5d2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ waf3-*
 .lock-waf*
 build
 VERSION*
+*symbols.ini
diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
new file mode 100644
index 000..54933d5
--- /dev/null
+++ b/tester/rt/coverage.py
@@ -0,0 +1,385 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS'
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+from rtemstoolkit import error
+from rtemstoolkit import path
+from rtemstoolkit import log
+from rtemstoolkit import execute
+from rtemstoolkit import macros
+
+from datetime import datetime
+
+from . import options
+
+import shutil
+import os
+
+try:
+import configparser
+except:
+import ConfigParser as configparser
+
+class summary:
+def __init__(self, p_summary_dir):
+self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
+self.index_file_path = path.join(p_summary_dir, 'index.html')
+self.bytes_analyzed = 0
+self.bytes_not_executed = 0
+self.percentage_executed = 0.0
+self.percentage_not_executed = 100.0
+self.ranges_uncovered = 0
+self.branches_uncovered = 0
+self.branches_total = 0
+self.branches_always_taken = 0
+self.branches_never_taken = 0
+self.percentage_branches_covered = 0.0
+self.is_failure = False
+
+def parse(self):
+if(not path.exists(self.summary_file_path)):
+log.notice('summary file %s does not exist!' % 
(self.summary_file_path))
+self.is_failure = True
+return
+
+with open(self.summary_file_path,'r') as summary_file:
+   self.bytes_analyzed = self._get_next_with_colon(summary_file)
+   self.bytes_not_executed = self._get_next_with_colon(summary_file)
+   self.percentage_executed = self._get_next_with_colon(summary_file)
+   self.percentage_not_executed = 
self._get_next_with_colon(summary_file)
+   self.ranges_uncovered = self._get_next_with_colon(summary_file)
+   self.branches_total = self._get_next_with_colon(summary_file)
+   self.branches_uncovered = self._get_next_with_colon(summary_file)
+   self.branches_always_taken = 
self._get_next_without_colon(summary_file)
+   self.branches_never_taken = 
self._get_next_without_colon(summary_file)
+if len(self.branches_uncovered) > 0 and len(self.branches_total) > 0:
+self.percentage_branches_covered = \
+1 - (float(self.branches_uncovered) / float(self.branches_total))
+else:
+self.percentage_branches_covered = 0.0
+return
+
+def _get_next_with_colon(self, summary_file):
+line = summary_file.readline()
+if ':' in line:
+return line.split(':')[1].strip()
+else:
+return ''
+
+

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 5 June 2018 at 01:28, Cillian O'Donnell  wrote:

>
>
> On 4 June 2018 at 20:29, Vijay Kumar Banerjee 
> wrote:
>
>> On 5 June 2018 at 00:51, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 5 June 2018 at 00:31, Joel Sherrill  wrote:
>>>>
>>>>> I will add that covoar was originally designed to generate a report on
>>>>> one
>>>>> set at a time. The iteration over symbol sets was done at the scripting
>>>>> level above that.
>>>>>
>>>>> This had the advantage of being simple at the time. It may still be
>>>>> simple
>>>>> but moving the iteration over sets to covoar will probably be faster.
>>>>>
>>>>> I think DesiredSymbols is instanced a single time. As a starting
>>>>> point, there
>>>>> would have to be multiple instances of this -- one for each symbol set.
>>>>>
>>>>> Beyond that, there is a correlation between the report generated and
>>>>> the desired symbols set.
>>>>>
>>>>> So I am thinking that we need to define a "context" structure for each
>>>>> set. One simple thought is that there is one "master/unified"
>>>>> DesiredSymbol
>>>>> set under the hood and the symbols in each set are used as a filter
>>>>> when generating reports. So process the executables for every symbol
>>>>> but generate the report subdirectories based on one of the sets of
>>>>> DesiredSymbols.
>>>>>
>>>>> I think that should work.
>>>>>
>>>>> Cillian.. you have been through the flow. Am I thinking right that it
>>>>> is
>>>>>
>>>> That sounds like it will work, I'll go back over the covoar code and
> have a think about it. See if I can find any road blocks.
>
>
>>
>>>>> And I think we need to merge before doing this type of work. If we can
>>>>> process
>>>>> a single set correctly, that's a baseline. Adding iteration will be
>>>>> easier to review
>>>>> as another patch.
>>>>>
>>>>>
>>>> we can process a single set correctly.
>>>> Shall we proceed with merging the above patch with the suggested small
>>>> edits
>>>> and then file a ticket for the iteration and then start working on it ?
>>>>
>>>
>>> Please.
>>>
>>>>
>>>> I am confused with running of coverage for multiple bsp. If a single
>>>> report.html has to show the reports of multiple bsps (as hinted by
>>>> Cillian)
>>>>
>>> Actually I meant separate report.htmls, but if they're all outputed in
> the the top level directory there'll have to be something internal to know
> to search for the right output directory with all the coverage data, that's
> all I meant. Nothing major.
>
>
>> Then a lot of rewroking would be needed. If we're headed in that way
>>>> then I think making separate report.html like leon3-report.html would
>>>> be simpler
>>>> to achieve, and then create a master index.html for listing all the
>>>> report htmls.
>>>>
>>>
>>> A single run of the tester will test a single BSP. If you open two shell
>>> windows
>>> and run the tester in both, will those collide?
>>>
>>> In it's current state. Yes, it will collide as all the names of files
>> (including report.html)
>> are constant. :(
>>
> This is the main fix for now just making adding unique identifiers for
> files and dirs that will be called in the process. Focus on that, then we
> can try and merge and the covoar fix for multi sets can come later.
>
I have added the update .
after the update the directory is BSP-coverage ( example :-
leon3-qemu-coverage)
they symbol file created is leon3-qemu-symbols.ini
I have made the necessary changes and leon3-qemu-report.html is showing
proper results.

> covoar does not need support internally to process multiple BSPs
>>> concurrently.
>>>
>>> It is common practice to build and test multiple BSPs in parallel to
>>> take advantage
>>> of machines with many cores.
>>>
>>> But if you aren't careful, you can't even have two build/test trees at
>>> the same time
>>> if they collide on file na

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 5 June 2018 at 00:51, Joel Sherrill  wrote:

>
>
> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 5 June 2018 at 00:31, Joel Sherrill  wrote:
>>
>>> I will add that covoar was originally designed to generate a report on
>>> one
>>> set at a time. The iteration over symbol sets was done at the scripting
>>> level above that.
>>>
>>> This had the advantage of being simple at the time. It may still be
>>> simple
>>> but moving the iteration over sets to covoar will probably be faster.
>>>
>>> I think DesiredSymbols is instanced a single time. As a starting point,
>>> there
>>> would have to be multiple instances of this -- one for each symbol set.
>>>
>>> Beyond that, there is a correlation between the report generated and
>>> the desired symbols set.
>>>
>>> So I am thinking that we need to define a "context" structure for each
>>> set. One simple thought is that there is one "master/unified"
>>> DesiredSymbol
>>> set under the hood and the symbols in each set are used as a filter
>>> when generating reports. So process the executables for every symbol
>>> but generate the report subdirectories based on one of the sets of
>>> DesiredSymbols.
>>>
>>> I think that should work.
>>>
>>> Cillian.. you have been through the flow. Am I thinking right that it is
>>>
>>> And I think we need to merge before doing this type of work. If we can
>>> process
>>> a single set correctly, that's a baseline. Adding iteration will be
>>> easier to review
>>> as another patch.
>>>
>>>
>> we can process a single set correctly.
>> Shall we proceed with merging the above patch with the suggested small
>> edits
>> and then file a ticket for the iteration and then start working on it ?
>>
>
> Please.
>
>>
>> I am confused with running of coverage for multiple bsp. If a single
>> report.html has to show the reports of multiple bsps (as hinted by
>> Cillian)
>> Then a lot of rewroking would be needed. If we're headed in that way
>> then I think making separate report.html like leon3-report.html would be
>> simpler
>> to achieve, and then create a master index.html for listing all the
>> report htmls.
>>
>
> A single run of the tester will test a single BSP. If you open two shell
> windows
> and run the tester in both, will those collide?
>
> In it's current state. Yes, it will collide as all the names of files
(including report.html)
are constant. :(

> covoar does not need support internally to process multiple BSPs
> concurrently.
>
> It is common practice to build and test multiple BSPs in parallel to take
> advantage
> of machines with many cores.
>
> But if you aren't careful, you can't even have two build/test trees at the
> same time
> if they collide on file names in shared directories.
>
> Does that make sense?
>
>
>>> On Mon, Jun 4, 2018 at 1:43 PM, Cillian O'Donnell >> > wrote:
>>>
>>>>
>>>>
>>>> On 4 June 2018 at 19:03, Vijay Kumar Banerjee >>> > wrote:
>>>>
>>>>> On 2 June 2018 at 01:00, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 2 June 2018 at 00:48, Joel Sherrill  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 1 June 2018 at 20:30, Gedare Bloom  wrote:
>>>>>>>>
>>>>>>>>> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>>>>>>>>>  wrote:
>>>>>>>>> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
>>>>>>>>> >>  wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Here's the list of Ideas for improvements:
>>>>>>>>> >>>
>>>>>>>>> >>> 1. Include the section coverage in the bs

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 5 June 2018 at 00:31, Joel Sherrill  wrote:

> I will add that covoar was originally designed to generate a report on one
> set at a time. The iteration over symbol sets was done at the scripting
> level above that.
>
> This had the advantage of being simple at the time. It may still be simple
> but moving the iteration over sets to covoar will probably be faster.
>
> I think DesiredSymbols is instanced a single time. As a starting point,
> there
> would have to be multiple instances of this -- one for each symbol set.
>
> Beyond that, there is a correlation between the report generated and
> the desired symbols set.
>
> So I am thinking that we need to define a "context" structure for each
> set. One simple thought is that there is one "master/unified" DesiredSymbol
> set under the hood and the symbols in each set are used as a filter
> when generating reports. So process the executables for every symbol
> but generate the report subdirectories based on one of the sets of
> DesiredSymbols.
>
> I think that should work.
>
> Cillian.. you have been through the flow. Am I thinking right that it is
>
> And I think we need to merge before doing this type of work. If we can
> process
> a single set correctly, that's a baseline. Adding iteration will be easier
> to review
> as another patch.
>
>
we can process a single set correctly.
Shall we proceed with merging the above patch with the suggested small edits
and then file a ticket for the iteration and then start working on it ?

I am confused with running of coverage for multiple bsp. If a single
report.html has to show the reports of multiple bsps (as hinted by Cillian)
Then a lot of rewroking would be needed. If we're headed in that way
then I think making separate report.html like leon3-report.html would be
simpler
to achieve, and then create a master index.html for listing all the report
htmls.

>
> On Mon, Jun 4, 2018 at 1:43 PM, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 4 June 2018 at 19:03, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 2 June 2018 at 01:00, Vijay Kumar Banerjee 
>>> wrote:
>>>
>>>> On 2 June 2018 at 00:48, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 1 June 2018 at 20:30, Gedare Bloom  wrote:
>>>>>>
>>>>>>> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>>>>>>>  wrote:
>>>>>>> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
>>>>>>> >>  wrote:
>>>>>>> >>>
>>>>>>> >>> Here's the list of Ideas for improvements:
>>>>>>> >>>
>>>>>>> >>> 1. Include the section coverage in the bsp config file.
>>>>>>> >>> If the section is not found then the script will show
>>>>>>> >>> proper error showing coverage is not supported for the
>>>>>>> >>> provided bsp config file.
>>>>>>> >>>
>>>>>>> >>> 2. Update covoar to add support for separate coverage report
>>>>>>> >>> for each symbol set.
>>>>>>> >>>
>>>>>>> >>> 3. Add a method somewhere in covoar to get the size of an
>>>>>>> instruction
>>>>>>> >>> and fix the hard coded size 4 in ObjdumpProcessor.cc
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> What about a single XXX_run command? What about that suggestion?
>>>>>>> >>
>>>>>>> > The suggestion was to turn test_run and coverage_run into a single
>>>>>>> command.
>>>>>>> > I have kept them separate so that there's a possibility to just
>>>>>>> run the
>>>>>>> > test.
>>>>>>> >
>>>>>>> > If we want to run coverage everytime we run the test. we can do it.
>>>>>>> > Then I think the --coverage option can be changed to
>>>>>>> --coverage-sets
>>>>>>> > to mention the sets.
>>>&g

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 2 June 2018 at 01:00, Vijay Kumar Banerjee 
wrote:

> On 2 June 2018 at 00:48, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 1 June 2018 at 20:30, Gedare Bloom  wrote:
>>>
>>>> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>>>>  wrote:
>>>> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
>>>> >>  wrote:
>>>> >>>
>>>> >>> Here's the list of Ideas for improvements:
>>>> >>>
>>>> >>> 1. Include the section coverage in the bsp config file.
>>>> >>> If the section is not found then the script will show
>>>> >>> proper error showing coverage is not supported for the
>>>> >>> provided bsp config file.
>>>> >>>
>>>> >>> 2. Update covoar to add support for separate coverage report
>>>> >>> for each symbol set.
>>>> >>>
>>>> >>> 3. Add a method somewhere in covoar to get the size of an
>>>> instruction
>>>> >>> and fix the hard coded size 4 in ObjdumpProcessor.cc
>>>> >>
>>>> >>
>>>> >> What about a single XXX_run command? What about that suggestion?
>>>> >>
>>>> > The suggestion was to turn test_run and coverage_run into a single
>>>> command.
>>>> > I have kept them separate so that there's a possibility to just run
>>>> the
>>>> > test.
>>>> >
>>>> > If we want to run coverage everytime we run the test. we can do it.
>>>> > Then I think the --coverage option can be changed to --coverage-sets
>>>> > to mention the sets.
>>>> > If that's what we're looking for then I don't think a separate ticket
>>>> is
>>>> > needed,
>>>> > I can try to do it within tomorrow and submit an updated patch.
>>>> >
>>>> >>
>>>> >> Will there be an update to this patch?
>>>> >>
>>>> > This patch is working an showing results. I don't have any work
>>>> > going related to this patch currently.
>>>> > If there are any suggestions, I'll try to include all the suggested
>>>> updates
>>>> > as soon as possible and submit. So that we can get it merged.
>>>> >
>>>>
>>>> I get confused by the similarity between test_run() and coverage_run()
>>>> names, and now I'm also seeing some confusion because there is a
>>>> function coverage_run() and a class coverage_run. I suggest you remove
>>>> this function coverage_run(), and make either coverage_run.__init__()
>>>> or coverage_run.run() take the executables as a parameter directly.
>>>>
>>>> Thank you for the suggestion. :)
>>> I have removed the function and taken executables as a parameter in
>>> coverage_run.__init__()
>>>
>>> I have a question.
>>> The ini file that is fed to covoar is written by the script according to
>>> the
>>> symbols mentioned by the user. I haven't include the ini file in the
>>> patch.
>>> I'm planning to delete the file after the run, unless --no-clean option
>>> is given,
>>> which currently deletes the .cov trace files after the run.
>>>
>>
>> That makes sense.
>>
>>
>>> Can I proceed with this ?
>>>
>>
>> Yes.
>>
> Added. Thanks. :)
>
>> also, shall I include that in the .gitignore ?
>>>
>>
>> Is the name of the file constant? The same across multiple BSPs? If so,
>> then this will be a problem doing automated testing of multiple BSPs in
>> parallel.
>>
>> The ini file I'm talking about is the symbol sets config file not the bsp
> config file. yes the name is constant. Should it be unique to the bsp ?
> something like, leon3-symbols.ini ?
> How does the automated testing work?
>
>> I think the name needs to be unique enough.to support running testing
>> with coverage on multiple BSPs in parallel. That means you can't add it to
>> gitignore. And can add another issue and FIXME to the code.
>>
>>> If it is needed then I have a fix in mind. I can take the bsp name and
> add
> '-symbols.ini' to it. and add *-symbols.ini to .gitignore .
>
Shall I add this or put a fixme in the code and post a patch ?
Are there any other suggestions for the patch ?

I was looking into covoar for generating separate reports for each
symbolset.
Seems like  all the coverage reports are generated together and are written
in the _outputDirectory_ . I couldn't figure out how to cleanly address
this.
If covoar is intended to generate reports from multiple
subsystems/symbolsets,
then I think this would be a needed update. Otherwise we can do it from the
script, by feeding covoar with a single set ini and putting the result in a
separate
directory .

> Can we do this ?
>
>>
>>>
>>>> -Gedare
>>>>
>>>
>>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 2 June 2018 at 00:48, Joel Sherrill  wrote:

>
>
> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 1 June 2018 at 20:30, Gedare Bloom  wrote:
>>
>>> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>>>  wrote:
>>> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
>>> >>  wrote:
>>> >>>
>>> >>> Here's the list of Ideas for improvements:
>>> >>>
>>> >>> 1. Include the section coverage in the bsp config file.
>>> >>> If the section is not found then the script will show
>>> >>> proper error showing coverage is not supported for the
>>> >>> provided bsp config file.
>>> >>>
>>> >>> 2. Update covoar to add support for separate coverage report
>>> >>> for each symbol set.
>>> >>>
>>> >>> 3. Add a method somewhere in covoar to get the size of an instruction
>>> >>> and fix the hard coded size 4 in ObjdumpProcessor.cc
>>> >>
>>> >>
>>> >> What about a single XXX_run command? What about that suggestion?
>>> >>
>>> > The suggestion was to turn test_run and coverage_run into a single
>>> command.
>>> > I have kept them separate so that there's a possibility to just run the
>>> > test.
>>> >
>>> > If we want to run coverage everytime we run the test. we can do it.
>>> > Then I think the --coverage option can be changed to --coverage-sets
>>> > to mention the sets.
>>> > If that's what we're looking for then I don't think a separate ticket
>>> is
>>> > needed,
>>> > I can try to do it within tomorrow and submit an updated patch.
>>> >
>>> >>
>>> >> Will there be an update to this patch?
>>> >>
>>> > This patch is working an showing results. I don't have any work
>>> > going related to this patch currently.
>>> > If there are any suggestions, I'll try to include all the suggested
>>> updates
>>> > as soon as possible and submit. So that we can get it merged.
>>> >
>>>
>>> I get confused by the similarity between test_run() and coverage_run()
>>> names, and now I'm also seeing some confusion because there is a
>>> function coverage_run() and a class coverage_run. I suggest you remove
>>> this function coverage_run(), and make either coverage_run.__init__()
>>> or coverage_run.run() take the executables as a parameter directly.
>>>
>>> Thank you for the suggestion. :)
>> I have removed the function and taken executables as a parameter in
>> coverage_run.__init__()
>>
>> I have a question.
>> The ini file that is fed to covoar is written by the script according to
>> the
>> symbols mentioned by the user. I haven't include the ini file in the
>> patch.
>> I'm planning to delete the file after the run, unless --no-clean option
>> is given,
>> which currently deletes the .cov trace files after the run.
>>
>
> That makes sense.
>
>
>> Can I proceed with this ?
>>
>
> Yes.
>
Added. Thanks. :)

> also, shall I include that in the .gitignore ?
>>
>
> Is the name of the file constant? The same across multiple BSPs? If so,
> then this will be a problem doing automated testing of multiple BSPs in
> parallel.
>
> The ini file I'm talking about is the symbol sets config file not the bsp
config file. yes the name is constant. Should it be unique to the bsp ?
something like, leon3-symbols.ini ?
How does the automated testing work?

> I think the name needs to be unique enough.to support running testing
> with coverage on multiple BSPs in parallel. That means you can't add it to
> gitignore. And can add another issue and FIXME to the code.
>
>> If it is needed then I have a fix in mind. I can take the bsp name and add
'-symbols.ini' to it. and add *-symbols.ini to .gitignore .
Can we do this ?

>
>>
>>> -Gedare
>>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 20:30, Gedare Bloom  wrote:

> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>  wrote:
> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
> >>  wrote:
> >>>
> >>> Here's the list of Ideas for improvements:
> >>>
> >>> 1. Include the section coverage in the bsp config file.
> >>> If the section is not found then the script will show
> >>> proper error showing coverage is not supported for the
> >>> provided bsp config file.
> >>>
> >>> 2. Update covoar to add support for separate coverage report
> >>> for each symbol set.
> >>>
> >>> 3. Add a method somewhere in covoar to get the size of an instruction
> >>> and fix the hard coded size 4 in ObjdumpProcessor.cc
> >>
> >>
> >> What about a single XXX_run command? What about that suggestion?
> >>
> > The suggestion was to turn test_run and coverage_run into a single
> command.
> > I have kept them separate so that there's a possibility to just run the
> > test.
> >
> > If we want to run coverage everytime we run the test. we can do it.
> > Then I think the --coverage option can be changed to --coverage-sets
> > to mention the sets.
> > If that's what we're looking for then I don't think a separate ticket is
> > needed,
> > I can try to do it within tomorrow and submit an updated patch.
> >
> >>
> >> Will there be an update to this patch?
> >>
> > This patch is working an showing results. I don't have any work
> > going related to this patch currently.
> > If there are any suggestions, I'll try to include all the suggested
> updates
> > as soon as possible and submit. So that we can get it merged.
> >
>
> I get confused by the similarity between test_run() and coverage_run()
> names, and now I'm also seeing some confusion because there is a
> function coverage_run() and a class coverage_run. I suggest you remove
> this function coverage_run(), and make either coverage_run.__init__()
> or coverage_run.run() take the executables as a parameter directly.
>
> Thank you for the suggestion. :)
I have removed the function and taken executables as a parameter in
coverage_run.__init__()

I have a question.
The ini file that is fed to covoar is written by the script according to the
symbols mentioned by the user. I haven't include the ini file in the patch.
I'm planning to delete the file after the run, unless --no-clean option is
given,
which currently deletes the .cov trace files after the run.

Can I proceed with this ?
also, shall I include that in the .gitignore ?


> -Gedare
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 19:24, Joel Sherrill  wrote:

>
>
> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Here's the list of Ideas for improvements:
>>
>> 1. Include the section coverage in the bsp config file.
>> If the section is not found then the script will show
>> proper error showing coverage is not supported for the
>> provided bsp config file.
>>
>> 2. Update covoar to add support for separate coverage report
>> for each symbol set.
>>
>> 3. Add a method somewhere in covoar to get the size of an instruction
>> and fix the hard coded size 4 in ObjdumpProcessor.cc
>>
>
> What about a single XXX_run command? What about that suggestion?
>
> The suggestion was to turn test_run and coverage_run into a single command.
I have kept them separate so that there's a possibility to just run the
test.

If we want to run coverage everytime we run the test. we can do it.
Then I think the --coverage option can be changed to --coverage-sets
to mention the sets.
If that's what we're looking for then I don't think a separate ticket is
needed,
I can try to do it within tomorrow and submit an updated patch.


> Will there be an update to this patch?
>
> This patch is working an showing results. I don't have any work
going related to this patch currently.
If there are any suggestions, I'll try to include all the suggested updates
as soon as possible and submit. So that we can get it merged.

Once I have the final patch, I think I will push it along with my two
> covoar patches. Those will keep the GSoC project moving on sparc
> until I can really fix the "+4" issue.
>
>>
>>
>> On 1 June 2018 at 04:43, Joel Sherrill  wrote:
>>
>>> Just chatted with Chris. The coverage BSP ini file was a temporary
>>> measure as I thought.
>>>
>>> Make a list of all the ideas we have had for improvements. We want
>>> the code to get onto master.
>>>
>>> The list should be converted to Trac tickets very soon. Then we can
>>> decide which are critical for GSoC, which Chris or I will work on, and
>>> which are part of your GSoC.
>>>
>>> --joel
>>>
>>> On Thu, May 31, 2018 at 5:18 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 1 Jun 2018, 03:40 Joel Sherrill,  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, May 31, 2018 at 4:57 PM, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 1 June 2018 at 02:50, Joel Sherrill  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 31, 2018 at 4:15 PM, Cillian O'Donnell <
>>>>>>> cpodonne...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 31 May 2018, 22:03 Vijay Kumar Banerjee, <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 1 June 2018 at 02:14, Cillian O'Donnell 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> There is now a seperate bsp config for coverage, leon3-qemu-cov.
>>>>>>>>>> That is enough to trigger coverage now and --coverage could be 
>>>>>>>>>> reserved for
>>>>>>>>>> picking sets, probably renamed to --coverage-sets=... Or require 
>>>>>>>>>> sets to be
>>>>>>>>>> chosen --coverage-sets=all or specific sets 
>>>>>>>>>> --coverage-sets=score,sapi,cor
>>>>>>>>>> e
>>>>>>>>>>
>>>>>>>>>> Actually the idea of having separate bsp configs for cov
>>>>>>>>> in each of the bsps will create a lot of files. The intention is
>>>>>>>>> to make it simple for the user. just adding --coverage
>>>>>>>>> should run coverage analysis. There's a plan to include
>>>>>>>>> the 'coverage' section into the bsp ini file, and hence the user
>>>>>>>>> wouldn't
>>>>>>>>> have to keep switching the bsp config files.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Actually that's exactly the

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

Here's the list of Ideas for improvements:

1. Include the section coverage in the bsp config file.
If the section is not found then the script will show
proper error showing coverage is not supported for the
provided bsp config file.

2. Update covoar to add support for separate coverage report
for each symbol set.

3. Add a method somewhere in covoar to get the size of an instruction
and fix the hard coded size 4 in ObjdumpProcessor.cc


On 1 June 2018 at 04:43, Joel Sherrill  wrote:

> Just chatted with Chris. The coverage BSP ini file was a temporary
> measure as I thought.
>
> Make a list of all the ideas we have had for improvements. We want
> the code to get onto master.
>
> The list should be converted to Trac tickets very soon. Then we can
> decide which are critical for GSoC, which Chris or I will work on, and
> which are part of your GSoC.
>
> --joel
>
> On Thu, May 31, 2018 at 5:18 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Fri, 1 Jun 2018, 03:40 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Thu, May 31, 2018 at 4:57 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 1 June 2018 at 02:50, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, May 31, 2018 at 4:15 PM, Cillian O'Donnell <
>>>>> cpodonne...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 31 May 2018, 22:03 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 1 June 2018 at 02:14, Cillian O'Donnell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> There is now a seperate bsp config for coverage, leon3-qemu-cov.
>>>>>>>> That is enough to trigger coverage now and --coverage could be 
>>>>>>>> reserved for
>>>>>>>> picking sets, probably renamed to --coverage-sets=... Or require sets 
>>>>>>>> to be
>>>>>>>> chosen --coverage-sets=all or specific sets 
>>>>>>>> --coverage-sets=score,sapi,cor
>>>>>>>> e
>>>>>>>>
>>>>>>>> Actually the idea of having separate bsp configs for cov
>>>>>>> in each of the bsps will create a lot of files. The intention is
>>>>>>> to make it simple for the user. just adding --coverage
>>>>>>> should run coverage analysis. There's a plan to include
>>>>>>> the 'coverage' section into the bsp ini file, and hence the user
>>>>>>> wouldn't
>>>>>>> have to keep switching the bsp config files.
>>>>>>>
>>>>>>
>>>>>> Actually that's exactly the way I had it working before Chris' recent
>>>>>> changes, he had a look at the way it's working and chose to create 
>>>>>> seperate
>>>>>> bsp config files. That may be the way he'd prefer. This was before the
>>>>>> --coverage option had another use other than triggering coverage, so his
>>>>>> thoughts may have changed on it.
>>>>>>
>>>>>
>>>>> Chris should comment on the separate ini files. I think that might
>>>>> have been
>>>>> driven by couverture vs regular qemu before couverture was available
>>>>> from
>>>>> the RSB.
>>>>>
>>>>> Okay, we wait for Chris to comment on it then.
>>>>
>>>>> I think it would be nice to have --coverage and if the BSP ini file
>>>>> doesn't support
>>>>> coverage, give an error.
>>>>>
>>>>>
>>>> Is the set option in the Python and processed by covoar in a way that
>>>>> still
>>>>> lets covoar be used on something besides RTEMS?
>>>>>
>>>>>
>>>> yes, it is totally handled by the script to 'feed' covoar with the
>>>> options,
>>>> without changing the way it works.
>>>>
>>>> I have a question/doubt.
>>>> By adding separate bsp config for cov. Are we not assuming that
>>>> the provided bsp ini supports coverage ?
>>>>
>>>
>>> I think having two leon3 configurations like we do now is temporary
>>> just to have something that works. Any changes to the cover

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On Fri, 1 Jun 2018, 03:40 Joel Sherrill,  wrote:

>
>
> On Thu, May 31, 2018 at 4:57 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 1 June 2018 at 02:50, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Thu, May 31, 2018 at 4:15 PM, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, 31 May 2018, 22:03 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 1 June 2018 at 02:14, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> There is now a seperate bsp config for coverage, leon3-qemu-cov. That
>>>>>> is enough to trigger coverage now and --coverage could be reserved for
>>>>>> picking sets, probably renamed to --coverage-sets=... Or require sets to 
>>>>>> be
>>>>>> chosen --coverage-sets=all or specific sets 
>>>>>> --coverage-sets=score,sapi,core
>>>>>>
>>>>>> Actually the idea of having separate bsp configs for cov
>>>>> in each of the bsps will create a lot of files. The intention is
>>>>> to make it simple for the user. just adding --coverage
>>>>> should run coverage analysis. There's a plan to include
>>>>> the 'coverage' section into the bsp ini file, and hence the user
>>>>> wouldn't
>>>>> have to keep switching the bsp config files.
>>>>>
>>>>
>>>> Actually that's exactly the way I had it working before Chris' recent
>>>> changes, he had a look at the way it's working and chose to create seperate
>>>> bsp config files. That may be the way he'd prefer. This was before the
>>>> --coverage option had another use other than triggering coverage, so his
>>>> thoughts may have changed on it.
>>>>
>>>
>>> Chris should comment on the separate ini files. I think that might have
>>> been
>>> driven by couverture vs regular qemu before couverture was available from
>>> the RSB.
>>>
>>> Okay, we wait for Chris to comment on it then.
>>
>>> I think it would be nice to have --coverage and if the BSP ini file
>>> doesn't support
>>> coverage, give an error.
>>>
>>>
>> Is the set option in the Python and processed by covoar in a way that
>>> still
>>> lets covoar be used on something besides RTEMS?
>>>
>>>
>> yes, it is totally handled by the script to 'feed' covoar with the
>> options,
>> without changing the way it works.
>>
>> I have a question/doubt.
>> By adding separate bsp config for cov. Are we not assuming that
>> the provided bsp ini supports coverage ?
>>
>
> I think having two leon3 configurations like we do now is temporary
> just to have something that works. Any changes to the coverage
> version don't impact the baseline.
>
Understood. Thanks.


> I am hoping Chris has an idea to unified these. :)
>
>
>>
>>
>>>>> The idea of modifying it to --coverage-sets=all ;
>>>>> --coverage-sets=set1,set2,set3. can surely be implemented
>>>>> in place of --coverage ; --coverage=set1,set2....
>>>>>
>>>>>> On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 1 June 2018 at 01:57, Cillian O'Donnell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> So is it checking whether it's --coverage or --coverage=set1,set2?
>>>>>>>> Are those the 2 possibilities your checking?
>>>>>>>>
>>>>>>>> Yes, right. :)
>>>>>>>
>>>>>>>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>>>>>>>>>  wrote:
>>>>>>>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell <
>>>>>>>>>> cpodonne...@gmail.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 02:50, Joel Sherrill  wrote:

>
>
> On Thu, May 31, 2018 at 4:15 PM, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Thu, 31 May 2018, 22:03 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 1 June 2018 at 02:14, Cillian O'Donnell 
>>> wrote:
>>>
>>>> There is now a seperate bsp config for coverage, leon3-qemu-cov. That
>>>> is enough to trigger coverage now and --coverage could be reserved for
>>>> picking sets, probably renamed to --coverage-sets=... Or require sets to be
>>>> chosen --coverage-sets=all or specific sets --coverage-sets=score,sapi,cor
>>>> e
>>>>
>>>> Actually the idea of having separate bsp configs for cov
>>> in each of the bsps will create a lot of files. The intention is
>>> to make it simple for the user. just adding --coverage
>>> should run coverage analysis. There's a plan to include
>>> the 'coverage' section into the bsp ini file, and hence the user wouldn't
>>> have to keep switching the bsp config files.
>>>
>>
>> Actually that's exactly the way I had it working before Chris' recent
>> changes, he had a look at the way it's working and chose to create seperate
>> bsp config files. That may be the way he'd prefer. This was before the
>> --coverage option had another use other than triggering coverage, so his
>> thoughts may have changed on it.
>>
>
> Chris should comment on the separate ini files. I think that might have
> been
> driven by couverture vs regular qemu before couverture was available from
> the RSB.
>
> Okay, we wait for Chris to comment on it then.

> I think it would be nice to have --coverage and if the BSP ini file
> doesn't support
> coverage, give an error.
>
>
Is the set option in the Python and processed by covoar in a way that still
> lets covoar be used on something besides RTEMS?
>
>
yes, it is totally handled by the script to 'feed' covoar with the options,
without changing the way it works.

I have a question/doubt.
By adding separate bsp config for cov. Are we not assuming that
the provided bsp ini supports coverage ?


>>> The idea of modifying it to --coverage-sets=all ;
>>> --coverage-sets=set1,set2,set3. can surely be implemented
>>> in place of --coverage ; --coverage=set1,set2
>>>
>>>> On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 1 June 2018 at 01:57, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> So is it checking whether it's --coverage or --coverage=set1,set2?
>>>>>> Are those the 2 possibilities your checking?
>>>>>>
>>>>>> Yes, right. :)
>>>>>
>>>>>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>>>>>>>
>>>>>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>>>>>>>  wrote:
>>>>>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9...@gmail.com>
>>>>>>>> >> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Add support in tester to run covoar and generate an html report
>>>>>>>> to
>>>>>>>> >>> display
>>>>>>>> >>> the summary of the coverage reports generated from covoar.
>>>>>>>> >>>
>>>>>>>> >>> Co-authored-by : Cillian O'Donnell 
>>>>>>>> >>> ---
>>>>>>>> >>>  tester/rt/coverage.py | 379
>>>>>>>> >>> ++
>>>>>>>> >>>  tester/rt/test.py |  36 ++-
>>>>>>>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>>>>>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>>>>>> >>>  tester/rtem

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 02:15, Gedare Bloom  wrote:

> On Thu, May 31, 2018 at 4:44 PM, Cillian O'Donnell
>  wrote:
> > There is now a seperate bsp config for coverage, leon3-qemu-cov. That is
> > enough to trigger coverage now and --coverage could be reserved for
> picking
> > sets, probably renamed to --coverage-sets=... Or require sets to be
> chosen
> > --coverage-sets=all or specific sets --coverage-sets=score,sapi,core
> >
> Yes, and it should work for more than 1 or 2.
>
> It can work for any number of sets.

> > On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com>
> > wrote:
> >>
> >> On 1 June 2018 at 01:57, Cillian O'Donnell 
> wrote:
> >>>
> >>> So is it checking whether it's --coverage or --coverage=set1,set2? Are
> >>> those the 2 possibilities your checking?
> >>>
> >> Yes, right. :)
> >>>
> >>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee,
> >>>  wrote:
> >>>>
> >>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
> >>>>>
> >>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
> >>>>>  wrote:
> >>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
> >>>>> > wrote:
> >>>>> >>
> >>>>> >>
> >>>>> >>
> >>>>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee
> >>>>> >> 
> >>>>> >> wrote:
> >>>>> >>>
> >>>>> >>> Add support in tester to run covoar and generate an html report
> to
> >>>>> >>> display
> >>>>> >>> the summary of the coverage reports generated from covoar.
> >>>>> >>>
> >>>>> >>> Co-authored-by : Cillian O'Donnell 
> >>>>> >>> ---
> >>>>> >>>  tester/rt/coverage.py | 379
> >>>>> >>> ++
> >>>>> >>>  tester/rt/test.py |  36 ++-
> >>>>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
> >>>>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
> >>>>> >>>  tester/rtems/testing/qemu.cfg |   4 +-
> >>>>> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
> >>>>> >>>  create mode 100644 tester/rt/coverage.py
> >>>>> >>>  create mode 100644 tester/rtems/testing/coverage/
> symbol-sets.ini
> >>>>> >>>
> >>>>> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> >>>>> >>> new file mode 100644
> >>>>> >>> index 000..25fbb9d
> >>>>> >>> --- /dev/null
> >>>>> >>> +++ b/tester/rt/coverage.py
> >>>>> >>> @@ -0,0 +1,379 @@
> >>>>> >>> +#
> >>>>> >>> +# RTEMS Tools Project (http://www.rtems.org/)
> >>>>> >>> +# Copyright 2014 Krzysztof Miesowicz
> >>>>> >>> (krzysztof.miesow...@gmail.com)
> >>>>> >>> +# All rights reserved.
> >>>>> >>> +#
> >>>>> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> >>>>> >>> +#
> >>>>> >>> +# Redistribution and use in source and binary forms, with or
> >>>>> >>> without
> >>>>> >>> +# modification, are permitted provided that the following
> >>>>> >>> conditions are
> >>>>> >>> met:
> >>>>> >>> +#
> >>>>> >>> +# 1. Redistributions of source code must retain the above
> >>>>> >>> copyright
> >>>>> >>> notice,
> >>>>> >>> +# this list of conditions and the following disclaimer.
> >>>>> >>> +#
> >>>>> >>> +# 2. Redistributions in binary form must reproduce the above
> >>>>> >>> copyright
> >>>>> >>> notice,
> >>>>> >>> +# this list of conditions and the following disclaimer in the
> >>>>> >&

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 02:14, Cillian O'Donnell  wrote:

> There is now a seperate bsp config for coverage, leon3-qemu-cov. That is
> enough to trigger coverage now and --coverage could be reserved for picking
> sets, probably renamed to --coverage-sets=... Or require sets to be chosen
> --coverage-sets=all or specific sets --coverage-sets=score,sapi,core
>
> Actually the idea of having separate bsp configs for cov
in each of the bsps will create a lot of files. The intention is
to make it simple for the user. just adding --coverage
should run coverage analysis. There's a plan to include
the 'coverage' section into the bsp ini file, and hence the user wouldn't
have to keep switching the bsp config files.

The idea of modifying it to --coverage-sets=all ;
--coverage-sets=set1,set2,set3. can surely be implemented
in place of --coverage ; --coverage=set1,set2

> On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, 
> wrote:
>
>> On 1 June 2018 at 01:57, Cillian O'Donnell  wrote:
>>
>>> So is it checking whether it's --coverage or --coverage=set1,set2? Are
>>> those the 2 possibilities your checking?
>>>
>>> Yes, right. :)
>>
>>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>>>>
>>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>>>>  wrote:
>>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
>>>>> wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> Add support in tester to run covoar and generate an html report to
>>>>> >>> display
>>>>> >>> the summary of the coverage reports generated from covoar.
>>>>> >>>
>>>>> >>> Co-authored-by : Cillian O'Donnell 
>>>>> >>> ---
>>>>> >>>  tester/rt/coverage.py | 379
>>>>> >>> ++
>>>>> >>>  tester/rt/test.py |  36 ++-
>>>>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>>> >>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>>> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
>>>>> >>>  create mode 100644 tester/rt/coverage.py
>>>>> >>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>>> >>>
>>>>> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>>>> >>> new file mode 100644
>>>>> >>> index 000..25fbb9d
>>>>> >>> --- /dev/null
>>>>> >>> +++ b/tester/rt/coverage.py
>>>>> >>> @@ -0,0 +1,379 @@
>>>>> >>> +#
>>>>> >>> +# RTEMS Tools Project (http://www.rtems.org/)
>>>>> >>> +# Copyright 2014 Krzysztof Miesowicz (
>>>>> krzysztof.miesow...@gmail.com)
>>>>> >>> +# All rights reserved.
>>>>> >>> +#
>>>>> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>> >>> +#
>>>>> >>> +# Redistribution and use in source and binary forms, with or
>>>>> without
>>>>> >>> +# modification, are permitted provided that the following
>>>>> conditions are
>>>>> >>> met:
>>>>> >>> +#
>>>>> >>> +# 1. Redistributions of source code must retain the above
>>>>> copyright
>>>>> >>> notice,
>>>>> >>> +# this list of conditions and the following disclaimer.
>>>>> >>> +#
>>>>> >>> +# 2. Redistributions in binary form must reproduce the above
>>>>> copyright
>>>>> >>> notice,
>>>>> >>> +# this list of conditions and the following disclaimer in the
>>>>> >>> documentation
>>>>> >>> +# and/or other materials provided with the distributi

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 01:19, Gedare Bloom  wrote:

> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>  wrote:
> > On 1 June 2018 at 01:07, Cillian O'Donnell 
> wrote:
> >>
> >>
> >>
> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee  >
> >> wrote:
> >>>
> >>> Add support in tester to run covoar and generate an html report to
> >>> display
> >>> the summary of the coverage reports generated from covoar.
> >>>
> >>> Co-authored-by : Cillian O'Donnell 
> >>> ---
> >>>  tester/rt/coverage.py | 379
> >>> ++
> >>>  tester/rt/test.py |  36 ++-
> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
> >>>  tester/rtems/testing/qemu.cfg |   4 +-
> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
> >>>  create mode 100644 tester/rt/coverage.py
> >>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
> >>>
> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> >>> new file mode 100644
> >>> index 000..25fbb9d
> >>> --- /dev/null
> >>> +++ b/tester/rt/coverage.py
> >>> @@ -0,0 +1,379 @@
> >>> +#
> >>> +# RTEMS Tools Project (http://www.rtems.org/)
> >>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
> >>> +# All rights reserved.
> >>> +#
> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> >>> +#
> >>> +# Redistribution and use in source and binary forms, with or without
> >>> +# modification, are permitted provided that the following conditions
> are
> >>> met:
> >>> +#
> >>> +# 1. Redistributions of source code must retain the above copyright
> >>> notice,
> >>> +# this list of conditions and the following disclaimer.
> >>> +#
> >>> +# 2. Redistributions in binary form must reproduce the above copyright
> >>> notice,
> >>> +# this list of conditions and the following disclaimer in the
> >>> documentation
> >>> +# and/or other materials provided with the distribution.
> >>> +#
> >>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >>> 'AS IS'
> >>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO,
> >>> THE
> >>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> >>> PURPOSE
> >>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS
> >>> BE
> >>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> >>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> >>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> >>> BUSINESS
> >>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> >>> IN
> >>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> >>> OTHERWISE)
> >>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF
> >>> THE
> >>> +# POSSIBILITY OF SUCH DAMAGE.
> >>> +#
> >>> +
> >>> +from rtemstoolkit import error
> >>> +from rtemstoolkit import path
> >>> +from rtemstoolkit import log
> >>> +from rtemstoolkit import execute
> >>> +from rtemstoolkit import macros
> >>> +
> >>> +from datetime import datetime
> >>> +
> >>> +from . import options
> >>> +
> >>> +import shutil
> >>> +import os
> >>> +
> >>> +try:
> >>> +import configparser
> >>> +except:
> >>> +import ConfigParser as configparser
> >>> +
> >>> +class summary:
> >>> +def __init__(self, p_summary_dir):
> >>> +self.summary_file_path = path.join(p_summary_dir,
> 'summary.txt')
> >>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
> >>> +self.bytes_analyzed = 0
> >>> +self.bytes_not_executed = 0
> >>> +self.percentage_executed = 0.0
> >>> +self.percentage_not_executed = 100.0
> 

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

On 1 June 2018 at 01:07, Cillian O'Donnell  wrote:

>
>
> On 31 May 2018 at 19:07, Vijay Kumar Banerjee 
> wrote:
>
>> Add support in tester to run covoar and generate an html report to display
>> the summary of the coverage reports generated from covoar.
>>
>> Co-authored-by : Cillian O'Donnell 
>> ---
>>  tester/rt/coverage.py | 379
>> ++
>>  tester/rt/test.py |  36 ++-
>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>  tester/rtems/testing/qemu.cfg |   4 +-
>>  5 files changed, 446 insertions(+), 12 deletions(-)
>>  create mode 100644 tester/rt/coverage.py
>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>
>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> new file mode 100644
>> index 000..25fbb9d
>> --- /dev/null
>> +++ b/tester/rt/coverage.py
>> @@ -0,0 +1,379 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions are
>> met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> 'AS IS'
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>> THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>> BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +from rtemstoolkit import error
>> +from rtemstoolkit import path
>> +from rtemstoolkit import log
>> +from rtemstoolkit import execute
>> +from rtemstoolkit import macros
>> +
>> +from datetime import datetime
>> +
>> +from . import options
>> +
>> +import shutil
>> +import os
>> +
>> +try:
>> +import configparser
>> +except:
>> +import ConfigParser as configparser
>> +
>> +class summary:
>> +def __init__(self, p_summary_dir):
>> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
>> +self.index_file_path = path.join(p_summary_dir, 'index.html')
>> +self.bytes_analyzed = 0
>> +self.bytes_not_executed = 0
>> +self.percentage_executed = 0.0
>> +self.percentage_not_executed = 100.0
>> +self.ranges_uncovered = 0
>> +self.branches_uncovered = 0
>> +self.branches_total = 0
>> +self.branches_always_taken = 0
>> +self.branches_never_taken = 0
>> +self.percentage_branches_covered = 0.0
>> +self.is_failure = False
>> +
>> +def parse(self):
>> +if(not path.exists(self.summary_file_path)):
>> +log.notice('summary file %s does not exist!' %
>> (self.summary_file_path))
>> +self.is_failure = True
>> +return
>> +
>> +with open(self.summary_file_path,'r') as summary_file:
>> +   self.bytes_analyzed = self._get_next_with_colon(summary_file)
>> +   self.bytes_not_executed = self._get_next_with_colon(summ
>> ary_file)
>> +   self.percentage_executed = self._get_next_with_colon(summ
>> ary_file)
>> +   self.percentage_not_executed = self._get_next_with_colon(summ
>> 

[PATCH v2] tester: Add script to generate html coverage report from covoar output

[Vijay Kumar Banerjee]

Add support in tester to run covoar and generate an html report to display
the summary of the coverage reports generated from covoar.

Co-authored-by : Cillian O'Donnell 
---
 tester/rt/coverage.py | 379 ++
 tester/rt/test.py |  36 ++-
 tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
 tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
 tester/rtems/testing/qemu.cfg |   4 +-
 5 files changed, 446 insertions(+), 12 deletions(-)
 create mode 100644 tester/rt/coverage.py
 create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini

diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
new file mode 100644
index 000..25fbb9d
--- /dev/null
+++ b/tester/rt/coverage.py
@@ -0,0 +1,379 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS'
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+from rtemstoolkit import error
+from rtemstoolkit import path
+from rtemstoolkit import log
+from rtemstoolkit import execute
+from rtemstoolkit import macros
+
+from datetime import datetime
+
+from . import options
+
+import shutil
+import os
+
+try:
+import configparser
+except:
+import ConfigParser as configparser
+
+class summary:
+def __init__(self, p_summary_dir):
+self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
+self.index_file_path = path.join(p_summary_dir, 'index.html')
+self.bytes_analyzed = 0
+self.bytes_not_executed = 0
+self.percentage_executed = 0.0
+self.percentage_not_executed = 100.0
+self.ranges_uncovered = 0
+self.branches_uncovered = 0
+self.branches_total = 0
+self.branches_always_taken = 0
+self.branches_never_taken = 0
+self.percentage_branches_covered = 0.0
+self.is_failure = False
+
+def parse(self):
+if(not path.exists(self.summary_file_path)):
+log.notice('summary file %s does not exist!' % 
(self.summary_file_path))
+self.is_failure = True
+return
+
+with open(self.summary_file_path,'r') as summary_file:
+   self.bytes_analyzed = self._get_next_with_colon(summary_file)
+   self.bytes_not_executed = self._get_next_with_colon(summary_file)
+   self.percentage_executed = self._get_next_with_colon(summary_file)
+   self.percentage_not_executed = 
self._get_next_with_colon(summary_file)
+   self.ranges_uncovered = self._get_next_with_colon(summary_file)
+   self.branches_total = self._get_next_with_colon(summary_file)
+   self.branches_uncovered = self._get_next_with_colon(summary_file)
+   self.branches_always_taken = 
self._get_next_without_colon(summary_file)
+   self.branches_never_taken = 
self._get_next_without_colon(summary_file)
+if len(self.branches_uncovered) > 0 and len(self.branches_total) > 0:
+self.percentage_branches_covered = \
+1 - (float(self.branches_uncovered) / float(self.branches_total))
+else:
+self.percentage_branches_covered = 0.0
+return
+
+def _get_next_with_colon(self, summary_file):
+line = summary_file.readline()
+if ':' in line:
+return line.split(':')[1].strip()
+else:
+return ''
+
+def _get_next_without_colon(self, summary_file):
+line = summary_file.readline()
+return line.strip().split(' ')[0]
+
+class report_gen_html:
+def __init__(self, p_symbol_sets_list, build_dir, rtdir):
+ 

Generating separate coverage reports for different symbol-sets from covoar

[Vijay Kumar Banerjee]

Hello,

The covoar currently is capable of processing multisets
from the symbol-sets ini file, however, it currently keeps
all the reports in the same directory (../coverage/score).

Before the recent updates to covoar it could only read
one set/subsystem from an ini file, and the script used
to loop over to feed covoar the ini files and store them
in a separate directory. Now this support needs to be
added to covoar .

The report.html generated from coverage has the
support for reading from different directories.
example:- ../coverage/score , ../coverage/rtems etc.
so just creating a directory for result in each iteration
of sets would solve this (I think)

-- vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 31 May 2018 at 02:02, Joel Sherrill  wrote:

>
>
> On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 31 May 2018 at 00:28, Joel Sherrill  wrote:
>>
>>>
>>>
>>> I may not understand correctly but there is test_run and coverage_run.
>>> Someone
>>> suggested making coverage_running an option to test_run. If that's
>>> what's being
>>> asked for, then I think doing it in a follow up patch is OK.
>>>
>>> If that's the intended request, perhaps a ticket should be filed.
>>>
>>>
>> Sorry for all the confusion.
>> This patch doesn't change the way test works. It only adds an option to
>> run
>> the coverage script. coverage_run just runs the coverage.coverage_run
>>
>
> :) And I am saying if we want to have one test_run with an argument, do it
> as
> a future work iteration. File a ticket.
>
> We need to get the code working on the master.
>
> Okay, we can keep that as a future work (I haven't thought about it
though). :)
Getting it to work on master is our primary objective.


>
>> >
>>>>>>> >  except error.general as gerr:
>>>>>>> >  print(gerr)
>>>>>>> > diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>>>>>> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>>>>>> > index 6b5e7e6..2f89117 100644
>>>>>>> > --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>>>>>> > +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>>>>>> > @@ -31,9 +31,10 @@
>>>>>>> >  #
>>>>>>> >  # The Leon 3 QEMU BSP
>>>>>>> >  #
>>>>>>> > -[leon3-qemu]
>>>>>>> > +[leon3-qemu-cov]
>>>>>>> >  bsp   = leon3-qemu
>>>>>>> >  arch  = sparc
>>>>>>> > +target= sparc-rtems5
>>>>>>> >  tester= %{_rtscripts}/qemu.cfg
>>>>>>> >  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>>>>>>> >  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
>>>>>>> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> > new file mode 100644
>>>>>>> > index 000..a2ec7bc
>>>>>>> > --- /dev/null
>>>>>>> > +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>>> > @@ -0,0 +1,36 @@
>>>>>>> > +#
>>>>>>> > +# RTEMS Tools Project (http://www.rtems.org/)
>>>>>>> > +# Copyright 2018 Chris Johns (chr...@rtems.org)
>>>>>>> > +# All rights reserved.
>>>>>>> > +#
>>>>>>> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>>>> > +#
>>>>>>> > +# Redistribution and use in source and binary forms, with or
>>>>>>> without
>>>>>>> > +# modification, are permitted provided that the following
>>>>>>> conditions are met:
>>>>>>> > +#
>>>>>>> > +# 1. Redistributions of source code must retain the above
>>>>>>> copyright notice,
>>>>>>> > +# this list of conditions and the following disclaimer.
>>>>>>> > +#
>>>>>>> > +# 2. Redistributions in binary form must reproduce the above
>>>>>>> copyright notice,
>>>>>>> > +# this list of conditions and the following disclaimer in the
>>>>>>> documentation
>>>>>>> > +# and/or other materials provided with the distribution.
>>>>>>> > +#
>>>>>>> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>>>>>>> CONTRIBUTORS "AS IS"
>>>>>>> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>>>>>> LIMITED TO, THE
>>>>>>> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>>>>>>> PARTICULAR PURPOSE
>>>>>>> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>>>>>>> CONTRIBUTORS BE
>>>>&g

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 31 May 2018 at 00:28, Joel Sherrill  wrote:

>
>
> I may not understand correctly but there is test_run and coverage_run.
> Someone
> suggested making coverage_running an option to test_run. If that's what's
> being
> asked for, then I think doing it in a follow up patch is OK.
>
> If that's the intended request, perhaps a ticket should be filed.
>
>
Sorry for all the confusion.
This patch doesn't change the way test works. It only adds an option to run
the coverage script. coverage_run just runs the coverage.coverage_run

> >
> >  except error.general as gerr:
> >  print(gerr)
> > diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > index 6b5e7e6..2f89117 100644
> > --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > @@ -31,9 +31,10 @@
> >  #
> >  # The Leon 3 QEMU BSP
> >  #
> > -[leon3-qemu]
> > +[leon3-qemu-cov]
> >  bsp   = leon3-qemu
> >  arch  = sparc
> > +target= sparc-rtems5
> >  tester= %{_rtscripts}/qemu.cfg
> >  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
> >  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
> b/tester/rtems/testing/coverage/symbol-sets.ini
> > new file mode 100644
> > index 000..a2ec7bc
> > --- /dev/null
> > +++ b/tester/rtems/testing/coverage/symbol-sets.ini
> > @@ -0,0 +1,36 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/)
> > +# Copyright 2018 Chris Johns (chr...@rtems.org)
> > +# All rights reserved.
> > +#
> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> > +#
> > +# Redistribution and use in source and binary forms, with or without
> > +# modification, are permitted provided that the following
> conditions are met:
> > +#
> > +# 1. Redistributions of source code must retain the above copyright
> notice,
> > +# this list of conditions and the following disclaimer.
> > +#
> > +# 2. Redistributions in binary form must reproduce the above
> copyright notice,
> > +# this list of conditions and the following disclaimer in the
> documentation
> > +# and/or other materials provided with the distribution.
> > +#
> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE
> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
> OR
> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> > +# POSSIBILITY OF SUCH DAMAGE.
> > +#
> > +
> > +[symbol-sets]
> > +sets = score,rtems
> > +
> > +[libraries]
> > +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
> > +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
> > diff --git a/tester/rtems/testing/qemu.cfg b/tester/rtems/testing/
> qemu.cfg
> > index bfcd2f5..52a3752 100644
> > --- a/tester/rtems/testing/qemu.cfg
> > +++ b/tester/rtems/testing/qemu.cfg
> > @@ -51,8 +51,8 @@
> >  #
> >  # Qemu common option patterns.
> >  #
> > -#%define qemu_opts_base   -no-reboot -monitor none -serial stdio
> -nographic
> > -%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
> -nographic
> > +%define qemu_opts_base   -no-reboot -monitor none -serial stdio
> -nographic
> > +#%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
> -nographic
>
> Why changing the common options for qemu?
>
> actually it's a bit experimental on advice of Cillian.
 It stayed in the patch.

>>>
>>> I know the impact of some of those options but maybe it would make sense
>>> to add a comment block with the impact of each option? It would help
>>> future
>>> readers.
>>>
>>> And, from personal experience, qemu changes arguments from time to time.
>>> Knowing
>>> what the old intent was helps mapping to different versions and target
>>> architectures.
>>>
>>> That's a good Idea.
>>
>>>
>>>
>>>
 >  %define qemu_opts_no_net -net none
> >
> >  #
> > --
> > 2.14.3
> >
> > 

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 30 May 2018 at 23:29, Joel Sherrill  wrote:

>
>
> On Wed, May 30, 2018 at 12:54 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 30 May 2018 at 22:51, Gedare Bloom  wrote:
>>
>>> Please provide your name in your commits (git config --user.name "My
>>> Name") that you submit.
>>>
>>> OK Noted :)
>>
>>> The first line of this commit, and therefore the email subject, is
>>> overly vague. Provide a slightly more specific description.
>>>
>> On Wed, May 30, 2018 at 1:00 PM, thelunatic 
>>> wrote:
>>> > + Add script to run covoar and generate an html report from
>>> > the output generated from covoar
>>> > + Add symbol-sets ini file for library addresses of the symbol-sets
>>> > + tester/rt/test : Add options for running coverage
>>> >
>>>
>>
>>> I'd rather see a narrative paragraph than this list of + bullet items.
>>> Are all of these changes required to run the report? Should they be
>>> broken into smaller commits that are logically related but separately
>>> reviewable and commited?
>>>
>>> OK, I will write in a descriptive paragraph.
>> These changes are all needed to run coverage.
>>
>>> > Co-author : Cillian O'Donnel 
>>> I don't know what Co-Author should mean. I would prefer to receive
>>> separate commits/patches for contributions made by different people if
>>> that is possible.
>>>
>>> Plese refer below...
>>
>>> > ---
>>> >  tester/rt/coverage.py | 380
>>> ++
>>> >  tester/rt/test.py |  36 ++-
>>> >  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>> >  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>> >  tester/rtems/testing/qemu.cfg |   4 +-
>>> >  5 files changed, 447 insertions(+), 12 deletions(-)
>>> >  create mode 100644 tester/rt/coverage.py
>>> >  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>> >
>>> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>> > new file mode 100644
>>> > index 000..38dcce6
>>> > --- /dev/null
>>> > +++ b/tester/rt/coverage.py
>>> > @@ -0,0 +1,380 @@
>>> > +#
>>> > +# RTEMS Tools Project (http://www.rtems.org/)
>>> > +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>>>
>>> Is this Krzysztof's code? if so, it should be added as a commit with
>>> him as the --author="" field of git-commit option.
>>>
>>> Actually this script has undergone a lot of updates.
>> It doesn't even work the same way it used to. I am uncertain
>> about the portions of the code that are written by him and still in
>> the script. Basically I left the copyright notice untouched and
>> let it be there because I am unsure of what to include there.
>> Same is true in case of Cillian. I don't really know how much
>> of Code is authored by him.
>> It surely isn't the proper way to add him as the co-author in
>> the log but that seemed like the only way to include him.
>>
>
> OK. I was afraid of it being technically impossible to separate out the
> work
> for revision control purposes.
>
> Just make sure credit due is given.
>
>
>>
>>
>>> > +# All rights reserved.
>>> > +#
>>> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>> > +#
>>> > +# Redistribution and use in source and binary forms, with or without
>>> > +# modification, are permitted provided that the following conditions
>>> are met:
>>> > +#
>>> > +# 1. Redistributions of source code must retain the above copyright
>>> notice,
>>> > +# this list of conditions and the following disclaimer.
>>> > +#
>>> > +# 2. Redistributions in binary form must reproduce the above
>>> copyright notice,
>>> > +# this list of conditions and the following disclaimer in the
>>> documentation
>>> > +# and/or other materials provided with the distribution.
>>> > +#
>>> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> 'AS IS'
>>> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>>> TO, THE
>>> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNES