Re: [GSOC - Tracing] Status Update

[Vidushi Vashishth]

>I am not sure you can do this without providing your own babeltrace
source component in a separate plugin to what is already available. If
the trace is not converted to a useful CTF format.

Yes. The blog post is merely to demonstrate how to use babeltrace. We will
not be dealing with text trace input to babeltrace. I am reading up on how
to create a customized plugin for RTEMS binary trace output for this.
Transporting ASCII files off the target will be a heavy operation hence
this is avoided.

Thanks



On Thu, Jul 5, 2018 at 4:04 AM, Guillaume Champagne <
guillaume.champa...@polymtl.ca> wrote:

> On Tue, 2018-07-03 at 07:50 +0530, Vidushi Vashishth wrote:
> > > 3. Clearly document your modifications in separate commit messages.
> >
> > > 4. Add a Makefile to build it automatically.
> >
> > I will push commits to a fork of the rtems. Have given a link to the
> > repository in the readme.md of the Tracing repo. Will that be okay?
> >
> > > 6. Document the steps involved in the tracing, e.g. trace data
> > generation on the RTEMS target, transfer of the data to the
> > development host, conversion of trace data in format X to Y using
> > tool Z, etc. Document the interfaces between the different steps and
> > what runs on the RTEMS target and what runs on the development host.
> >
> > Done
> >
> > > To get the trace data from the simulator to the development host,
> > you can just dump the data via printf() and parse it on the host.
> > This is slow, but enough for a test scenario.
> >
> > I have tested the babeltrace conversion by saving the console output
> > to a text file on host manually (https://vidushivashishth.github.io/e
> > ighthpost/). Can I use sockets to transport the traces from target to
> > host instead? Will that be feasible? I have already created a client
> > and server side program and tested a text file transfer. This is
> > working.
> >
>
> I tried the example in your blog post which works without `sudo` with
> babeltrace 2.0.0-pre4 on fedora. However, I am not sure the ctf output
> is correct. Each line in the original trace is dumped in a ctf event
> named "string" since the example uses the source `text.dmesg`. This
> source is usually used to parse the output of the dmesg linux tool [1].
>
> string: { }, { str = "0:00:26.7031882952081911  0a010002 [  2/  2]
> > malloc((size_t) 0130)" }
> string: { }, { str = "0:00:26.703324403 136108  0a010002 [  2/  2]
> < malloc => (void*) 0x219be08" }
> [..]
>
> This should be changed to actually split the data into correct CTF
> event field and header, like lttng-ust does:
>
> [18:14:22.611410669] (+0.01652) station12.dorsal.polymtl.ca
> lttng_ust_cyg_profile:func_entry: { cpu_id = 5 }, { vpid = 21117, vtid =
> 21117, procname = "demo" }, { addr = 0x7FF848DB6E21, call_site =
> 0x7FF848DB7856 }
> [..]
>
> I am not sure you can do this without providing your own babeltrace
> source component in a separate plugin to what is already available. If
> the trace is not converted to a useful CTF format, Trace Compass won't
> provide any useful analyses since it won't know what the event or the
> payload means.
>
> [1] http://man7.org/linux/man-pages/man7/babeltrace-source.text.dmesg.7
> .html
>
> Guillaume
>
> > > Either we should use barectf to generate CTF traces in RTEMS, we
> > > should implement our own CTF generator in RTEMS, or we should
> > provide
> > > a converter for running babeltrace on a host (Linux/MacOS/etc) to
> > > convert from RTEMS trace linker format to CTF.
> >
> > I am implementing the last option.
> >
> > On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom 
> > wrote:
> > > On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
> > >  wrote:
> > > > Hello Vidushi,
> > > >
> > > > On 29/06/18 09:44, Vidushi Vashishth wrote:
> > > >>
> > > >>
> > > >> >Could you please create a self-contained repository
> > > which
> > > >> contains
> > > >>
> > > >> >* a README
> > > >>
> > > >> >* a simple RTEMS application which runs on a simulator
> > > BSP
> > > >>
> > > >> >* the stuff that makes it possible to view the trace
> > > output
> > > >> (it is not a problem if it doesn't work, but all pieces
> > > should
> > > >> be included)
> > > >>
> > > >> >The repository should not be a clone of some larger
> > > project.
> > > >> It may contain external references as submodules.
> > > >>
> > > >> Okay. Got it. I will update you when its done.
> > > >>
> > > >>
> > > >> Ok, do you have a time estimate for this? Which parts are
> > > missing?
> > > >>
> > > >>
> > > >> Viewing the trace output is buggy right now. I will have to
> > > combine the
> > > >> rest. I will push the required things in the repository by end
> > > of today and
> > > >> notify you.
> > > >>
> > > >
> > > > the stuff you published here
> > > >
> > > > https://github.com/VidushiVashishth/Tracing
> > > >
> > > > yesterday (this is not "by end of today") is not much considering
> > > this the
> 

Re: [GSOC - Tracing] Status Update

[Guillaume Champagne]

On Tue, 2018-07-03 at 07:50 +0530, Vidushi Vashishth wrote:
> > 3. Clearly document your modifications in separate commit messages.
> 
> > 4. Add a Makefile to build it automatically.
> 
> I will push commits to a fork of the rtems. Have given a link to the
> repository in the readme.md of the Tracing repo. Will that be okay?
> 
> > 6. Document the steps involved in the tracing, e.g. trace data
> generation on the RTEMS target, transfer of the data to the
> development host, conversion of trace data in format X to Y using
> tool Z, etc. Document the interfaces between the different steps and
> what runs on the RTEMS target and what runs on the development host.
> 
> Done
> 
> > To get the trace data from the simulator to the development host,
> you can just dump the data via printf() and parse it on the host.
> This is slow, but enough for a test scenario.
> 
> I have tested the babeltrace conversion by saving the console output
> to a text file on host manually (https://vidushivashishth.github.io/e
> ighthpost/). Can I use sockets to transport the traces from target to
> host instead? Will that be feasible? I have already created a client
> and server side program and tested a text file transfer. This is
> working.
> 

I tried the example in your blog post which works without `sudo` with
babeltrace 2.0.0-pre4 on fedora. However, I am not sure the ctf output
is correct. Each line in the original trace is dumped in a ctf event
named "string" since the example uses the source `text.dmesg`. This
source is usually used to parse the output of the dmesg linux tool [1].

string: { }, { str = "0:00:26.7031882952081911  0a010002 [  2/  2]
> malloc((size_t) 0130)" }
string: { }, { str = "0:00:26.703324403 136108  0a010002 [  2/  2]
< malloc => (void*) 0x219be08" }
[..]

This should be changed to actually split the data into correct CTF
event field and header, like lttng-ust does:

[18:14:22.611410669] (+0.01652) station12.dorsal.polymtl.ca 
lttng_ust_cyg_profile:func_entry: { cpu_id = 5 }, { vpid = 21117, vtid = 21117, 
procname = "demo" }, { addr = 0x7FF848DB6E21, call_site = 0x7FF848DB7856 }
[..]

I am not sure you can do this without providing your own babeltrace
source component in a separate plugin to what is already available. If
the trace is not converted to a useful CTF format, Trace Compass won't
provide any useful analyses since it won't know what the event or the
payload means.

[1] http://man7.org/linux/man-pages/man7/babeltrace-source.text.dmesg.7
.html

Guillaume

> > Either we should use barectf to generate CTF traces in RTEMS, we
> > should implement our own CTF generator in RTEMS, or we should
> provide
> > a converter for running babeltrace on a host (Linux/MacOS/etc) to
> > convert from RTEMS trace linker format to CTF.
> 
> I am implementing the last option. 
> 
> On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom 
> wrote:
> > On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
> >  wrote:
> > > Hello Vidushi,
> > >
> > > On 29/06/18 09:44, Vidushi Vashishth wrote:
> > >>
> > >>
> > >> >Could you please create a self-contained repository
> > which
> > >> contains
> > >>
> > >> >* a README
> > >>
> > >> >* a simple RTEMS application which runs on a simulator
> > BSP
> > >>
> > >> >* the stuff that makes it possible to view the trace
> > output
> > >> (it is not a problem if it doesn't work, but all pieces
> > should
> > >> be included)
> > >>
> > >> >The repository should not be a clone of some larger
> > project.
> > >> It may contain external references as submodules.
> > >>
> > >> Okay. Got it. I will update you when its done.
> > >>
> > >>
> > >> Ok, do you have a time estimate for this? Which parts are
> > missing?
> > >>
> > >>
> > >> Viewing the trace output is buggy right now. I will have to
> > combine the
> > >> rest. I will push the required things in the repository by end
> > of today and
> > >> notify you.
> > >>
> > >
> > > the stuff you published here
> > >
> > > https://github.com/VidushiVashishth/Tracing
> > >
> > > yesterday (this is not "by end of today") is not much considering
> > this the
> > > 8th week of the GSoC project.
> > >
> > > You seem to have imported cpukit/libmisc/shell/main_rtrace.c and
> > modified
> > > it. The modifications are not visible in the repository history.
> > Why did yo
> > > copy this file out of the RTEMS sources at all?
> > >
> > > There is no Makefile (or similar). You have to read the
> > documentation to
> > > build it. You cannot copy and past the instructions to build it
> > since it
> > > contains your local paths.
> > >
> > > The test data is generated with user input.
> > >
> > > How can I transfer the test data generated on the simulator to my
> > host
> > > development system?
> > >
> > > I asked for a self-contained repository, with"the stuff that
> > makes it
> > > possible to view the trace output". This is missing.
> > >
> > > Could you please:
> > >

[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

[Joel Sherrill]

On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee 
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 >> > > 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.
>>>
>>
>> It has the runtime exception and is the only file that defines the format
>> of gcno and (need to double-check) gcda file. It does not contaminate
>> anything.
>>
>> I don't see anyway to interpret gcno or write gcda data otherwise.
>>
>> How does llvm address this? Don't that have the same issue?
>>
>> llvm defines it in GCOV.h file in llvm/ProfileData/ under the license
> it's mentioned there that it's distributed under University of Illinois
> Open Source License
>
> https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ProfileData/GCOV.h
> 
>

That would be the preferred way to get this header. Is it technically
acceptable?

Chris.. license acceptable to you?

>
> Ultimately we have two file formats that we have to deal with that GCC for
>> sure defines and llvm might also.
>>
>>
>>> > > 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?
>>>
>>
>> Llvm would be the only option but this has the rules time exception like
>> the RTEMS historical license so it non-viral.
>>
>> A hack would be to ensure they are installed with the RTEMS GCC by the
>> RSB. But that would be lifting a file out of the GCC source and  one from
>> the build tree that are normally not installed. We could ask about GCC
>> doing that.
>>
>> > >
>>> > > 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?
>>>
>>
>> Gcov reads gcda files for execution information. Rather than the
>> executable being instrumented and writing this during execution (libgcov),
>> covoar generates gcda files for unmodified executables using simulator
>> trace information. But you have to read gcno files and write gcda files.
>>
>>
>>
>>> 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.
>>
>> It is the path to another report format.
>>
>>>
>>> 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

Re: Gcov support in Covoar

[Joel Sherrill]

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  > > 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.
>

It has the runtime exception and is the only file that defines the format
of gcno and (need to double-check) gcda file. It does not contaminate
anything.

I don't see anyway to interpret gcno or write gcda data otherwise.

How does llvm address this? Don't that have the same issue?

Ultimately we have two file formats that we have to deal with that GCC for
sure defines and llvm might also.


> > > 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?
>

Llvm would be the only option but this has the rules time exception like
the RTEMS historical license so it non-viral.

A hack would be to ensure they are installed with the RTEMS GCC by the RSB.
But that would be lifting a file out of the GCC source and  one from the
build tree that are normally not installed. We could ask about GCC doing
that.

> >
> > > 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?
>

Gcov reads gcda files for execution information. Rather than the executable
being instrumented and writing this during execution (libgcov), covoar
generates gcda files for unmodified executables using simulator trace
information. But you have to read gcno files and write gcda files.



> 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.

It is the path to another report format.

>
> 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

Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP

[Amaan Cheval]

Hi!

Quick question - when I squash and submit the patches to devel, do 2
commits make sense?
1. Initial BSP that can build completely and get to the user's Init task
2. NS16550 console driver that lets printf/printk work

Another question - my code has a bunch of XXX comments in it - are we
okay to leave that as-is? Should I be changing some to TODOs, as
appropriate (seems like unnecessary effort since the BSP is still in
flux a fair bit).

I've made a WIP pull-request on Github to make some early feedback
easier (patches on the mailing list would likely feel cluttered for
this much code, I think). There's a bunch of clean-up left before I'll
squash (see the to-do in the PR), but I'd appreciate a skimmed review
if possible for anything else I need to do pre-merge:
https://github.com/AmaanC/rtems-gsoc18/pull/1

Let me know what you think!

On Sun, Jul 1, 2018 at 7:06 AM, Chris Johns  wrote:
>
>> On 29 Jun 2018, at 11:37 pm, Amaan Cheval  wrote:
>>
>> On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber
>>  wrote:
>>>
>>> From my point of view we can merge this stuff right now if the license and
>>> copyright status is clear of all files and it builds all tests.
>>
>> Noted. I'll start cleaning right away, then, unless someone disagrees soon.
>>
>
> I am happy to see this code merged as soon as possible.
>
> 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:36, Chris Johns  wrote:

>
>
> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> > 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
>
> 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

[Chris Johns]

On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
> 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 

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?

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

Re: Gcov support in Covoar

[Chris Johns]

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?

> 
> 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?
> 
> 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

Re: Gcov support in Covoar

[Chris Johns]

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?

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?

Chris
___
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