[PATCH v2 2/2] Adding trace documentation

[Vidushi Vashishth]

- Incorporated suggested changes (except making use case example as close to 
the actual output)
- Added trace linker section (to be completed)
- Added capture engine section
- Added trace buffering and printk trace generation in introduction
- Added trace examples section (to be completed)

The only tool to be installed is babeltrace which is in the introduction page 
under the babeltrace heading.
This documentation covers the following links:
1) https://devel.rtems.org/wiki/Developer/Tracing
2) https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering
3) https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
4) 
https://devel.rtems.org/attachment/wiki/Developer/Tracing/Trace_Buffering/fileio-trace.ini
5) https://ftp.rtems.org/pub/rtems/people/chrisj/capture/capture-pc586.txt
6) http://diamon.org/ctf/
7) http://diamon.org/babeltrace/
---
 user/index.rst |   2 +
 user/tracing/captureengine.rst | 167 +++
 user/tracing/examples.rst  |  11 ++
 user/tracing/index.rst |  26 +
 user/tracing/introduction.rst  | 150 
 user/tracing/tracelinker.rst   | 253 +
 user/tracing/usecases.rst  | 110 ++
 7 files changed, 719 insertions(+)
 create mode 100644 user/tracing/captureengine.rst
 create mode 100644 user/tracing/examples.rst
 create mode 100644 user/tracing/index.rst
 create mode 100644 user/tracing/introduction.rst
 create mode 100644 user/tracing/tracelinker.rst
 create mode 100644 user/tracing/usecases.rst

diff --git a/user/index.rst b/user/index.rst
index 8cbcd1b..a764fe8 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -52,6 +52,8 @@ to the Community Project hosted at http://www.rtems.org/.
 
tools/index
 
+tracing/index
+
support/index
 
glossary/index
diff --git a/user/tracing/captureengine.rst b/user/tracing/captureengine.rst
new file mode 100644
index 000..49f8a58
--- /dev/null
+++ b/user/tracing/captureengine.rst
@@ -0,0 +1,167 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. comment: Copyright (c) 2016 Chris Johns 
+.. comment: All rights reserved.
+
+.. _capturengine:
+
+Capture Engine
+**
+
+Capture Engine is a trace tool built inside the RTEMS operating system. 
Capture Engine
+is designed to cause the lowest load on the system when operating. Hence it 
does not
+effect RTEMS when operating or when disabled. It binds to RTEMS at runtime and 
does not
+require RTEMS or your application to be rebuilt in order to use it. 
+ 
+The Capture Engine's sample testcase for the `sparc/erc32` is available in the
+"$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples" 
directory,
+provided you followed the installation directions of the quickstart section. 
In order to
+access the capture testcase perform the following set of operations.
+
+.. code-block:: shell
+
+  $ cd 
$HOME/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples
+  $ ../samples
+  $ sparc-rtems5-run ./capture.exe
+
+
+  *** BEGIN OF TEST CAPTURE ENGINE ***
+  *** TEST VERSION: 5.0.0.de9b7d712bf5da6593386fd4fbca0d5f8b8431d8
+  *** TEST STATE: USER_INPUT
+  *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
+  *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB 
a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0)
+  Press any key to start capture engine (20s remaining)
+  Press any key to start capture engine (19s remaining)
+  Press any key to start capture engine (18s remaining)
+
+  Monitor ready, press enter to login.
+
+  1-rtems $
+
+Capture Engine comes with a set of commands to perform various actions. 
+
+Capture Engine Commands
+---
+
+1) ``copen ``: Used to initialize the Capture Engine with the 
trace buffer size in bytes. By default the Capture Engine is not initialized 
and not running.
+
+2) ``cwceil ``: Capture Engine filter used to put an upper 
limit on the event priority to be captured. 
+
+
+3) ``cwfloor ``: Capture Engine filter used to put a lower 
limit on the event priority to be captured.
+
+
+4) ``cwglob ``: Enable or disable the global watch. 
+
+
+5) ``cenable``: Enables the Capture Engine. Capture Engine is by default 
disabled after being opened.
+
+
+6) ``cdisable``: Disables the Capture Engine. 
+
+
+7) ``ctlist``: Lists the watch and trigger configurations. 
+
+
+8) ``ctrace``: Dumps the recorded traces. By default this command displays 24 
trace records. Repeated use of this command will display all the recorded 
traces. 
+
+9) ``cwadd ``: Add watch on a particular task.
+
+
+10) ``cwtctl  ``: Enable or disable watch on a particular 
task.
+
+  
+11) ``ctset``: Used to set a trigger. The general form of the command is:
+
+``ctset [-?] type [to name/id] [from] [from name/id]``
+
+'type' in the above command refers to the type of trigger needed. The types of 
triggers that currently exist
+are:
+
+- switch  : a context switch from one task to another ta

Re: error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

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.

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

Re: error while building leon3 with gcov flags

[Joel Sherrill]

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.

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

Re: error while building leon3 with gcov flags

[Joel Sherrill]

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.

On Sat, Jun 9, 2018, 3:34 PM Vijay Kumar Banerjee 
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
>>> 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.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 Sh

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

Re: error while building leon3 with gcov flags

[Joel Sherrill]

On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee 
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?

My reading of the gcc manual was that one of those options implicitly added
an option to link with libgcov.a. please confirm that.

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

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


 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

Re: error while building leon3 with gcov flags

[Joel Sherrill]

On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee 
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?



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

 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 t

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

Re: [GSoC - x86_64 BSP] Using fPIC to compile RTEMS as a shared library

[Joel Sherrill]

On Fri, Jun 8, 2018 at 7:45 PM, Chris Johns  wrote:

> On 9/6/18 10:00 am, Joel Sherrill wrote:
> > On Thu, Jun 7, 2018, 9:01 PM Chris Johns  > > wrote:
> > > and what
> > > discussions we need to have to decide between the "bundled
> kernel.so approach"
> > > (the one implemented here) vs. the "FreeBSD loader.efi+hello.exe"
> > approach. Let
> > > me know!
> > >
> >
> > I do not think I can help too much here. I understand the
> loader.efi+exe
> > solution and it should work because all RTEMS applications we have
> are
> > statically linked (I am assuming it is here). I have not looked at
> the details
> > being used with the -fPIC and .so solution so I cannot comment. I do
> have some
> > concerns the relocatable exe might expose some dark corners and
> issues in the
> > host tools we have, for example how does GDB find the base address
> of the image
> > so you can debug it? and is this just working or is it really
> suppose to work
> > this way?
> >
> >
> > All I can say is that with Deos/RTEMS, we use PIC on arm, PowerPC, and
> x86.
>
> I would hope a solution like Deos did provide a seamless way to do this
> and I
> would also hope they support you.
>

I am not using their normal recommended tool setup for users. This is normal
RTEMS tools building our test executables. At one point, it was our gdb with
their qemu build. They use something like this strictly internally.

These executables are statically linked EXCEPT for references to, in
the minimum case, two .so's from their environment. I set an argument to
ld to ensure all symbols are resolved at link time. Their boot process
associates
the .so files with the partitions. It is dynamic loading but it is
statically configured
and not touched after boot.

I haven't had any special help from them in this area except figuring out
the
arguments and linker scripts. When I have access to a build log, I am happy
to post the build of hello world for comparison.

I have no idea how this compares to UEFI booting except to say that PIC
hasn't introduced any tool issues in our GNU tools. libdl may have issues
but we aren't using it yet. I can check if the tests pass or are disabled. I
don't remember. But that may be illuminating.


>
> > We
> > have spent a lot of time debugging with gdb attached to qemu.
> How does GDB get the relocatable load address to map to the symbol table?
>
> The libdl code supports the same protocol/design as NetBSD and other
> systems in
> informing GDB about the address of loaded modules. There is a series of
> symbols
> and tables maintained that GDB knows to examine to find the load addresses
> of
> object files.
>
> > I haven't seen any tools issues yet.
>
> Yet?  Once the path is settled it will be difficult to change so all I am
> asking
> is the detail be checked and understood. RTEMS does not support shared
> libraries
> the same way Linux or other Unix systems do. I do not understand enough of
> the
> low level and the standards all this is based on to help decide.
>
> An example of an issue where a relocatable kernel with an unknown load
> address
> creates a problem is libdl. The testsuite uses the 2-pass approach
> (rtems-syms
> --embed) which should be OK however the other approach where the symbol
> table is
> not embedded and built on the host would fail. It is a small issue but it
> shows
> how things can subtly break.


I'm not relocating any RTEMS code with Deos. Our code is linked to a static
address
ranges and invokes Deos methods in the shared libbary.

I know this doesn't prove anything concretely about the UEFI exe  but it is
the closest
example we have. PIC is likely OK. The .so magic could be problematic as it
looks
like I effectively build a static exe.

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

Re: error while building leon3 with gcov flags

[Joel Sherrill]

On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee 
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.

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

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