Ticket #3515

Bran S archsbran at gmail.com
Tue Feb 4 06:03:52 UTC 2020


On Saturday, 1 February 2020, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:
>
>
>
> On Sat, Feb 1, 2020 at 9:31 PM Bran S <archsbran at gmail.com> wrote:
>>
>> On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:
>> >
>> > On Sat, Feb 1, 2020 at 12:57 PM Bran S <archsbran at gmail.com> wrote:
>> >>
>> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns <chrisj at rtems.org> wrote:
>> >> >
>> >> > On 29/1/20 7:03 pm, Bran S wrote:
>> >> > > Hi Guys,
>> >> > >
>> >> > > I am trying to solve #3515
>> >> > > https://devel.rtems.org/ticket/3515 <
https://devel.rtems.org/ticket/3515>
>> >> >
>> >> > Nice and thanks.
>> >> >
>> >> > > For this issue covoar is required.
>> >> > >
>> >> > > So I cloned https://git.rtems.org/rtems-tools/ <
https://git.rtems.org/rtems-tools/>
>> >> > > This is my directory structure:
>> >> > > $HOME/quick-start/src/rtems - Main RTEMS repo
>> >> > > $HOME/quick-start/src/rsb - Source Builder
>> >> > > $HOME/quick-start/src/rtems-tools - The one that I have recently
cloned
>> >> > >
>> >> > > But running `rtems-test --list-bsps` inside
'$HOME/quick-start/src/rtems-tools'
>> >> > > gives "error: RTEMS Toolkit python wrapper not found, plrease
report"
>> >> > >
>> >> > > Any ideas on how to resolve this error ?
>> >> >
>> >> > What does `type rtems-test` say?
>> >> >
>> >> > Have you built a set of sparc tools?
>> >> > Have you build the leon3 BSP and all the tests?
>> >> >
>> >> > I am not sure what happens if the `rtems-test` is run in the source
tree while
>> >> > picking up a version from your path. Maybe `./tester/rtems-test
...` works?
>> >>
>> > Hi Bran,
>> >
>> > Thanks for taking up this ticket.
>> >>
>> >> It is now working my $PATH was wrongly set with rtems/4.11 instead of
rtems/5.
>> >> I have corrected it. It now contains '$HOME/quick-start/rtems/5/bin'
>> >>
>> > Nice.
>> >>
>> >> Moving on to the next problem:
>> >>
https://devel.rtems.org/wiki/GCI/Documentation/CoverageAnalysis/Coverage#RunningRTEMS-TESTERforCoverageanalysis
>> >> I was reading this to know more about covoar.
>> >> So as mentioned above I ran
>> >>
>> >> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
>> >> --log=coverage_analysis.log --no-clean --coverage=score
>> >> --rtems-bsp=leon3-qemu-cov
>> >>
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
>> >>
>> >> And the output was: https://paste.debian.net/1128608/
>> >> `qemu-system-sparc` not being installed seems to be the cause for the
error.
>> >>
>> >> So I followed suggestion found here:
>> >> https://lists.rtems.org/pipermail/users/2018-January/065583.html
>> >> Ran the commands as:
>> >>
>> >> $ cd /quick-start/src/rsb/rtems/
>> >> The rsb directory contains rtems source builder.
>> >>
>> >> $ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> >> devel/qemu.bset
>> >>
>> > You need devel/qemu-couverture.bset but while trying to build it, I
see the same error
>> > as you see with qemu.bset
>> >>
>> >> Running this further gives errors and reports it into
>> >> 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt'
>> >> Full output of above command is at: https://paste.debian.net/1128609/
>> >>
>> >> The content of 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' is
>> >> here: https://paste.debian.net/1128610/
>> >>
>> >> In file 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' (at
>> >> https://paste.debian.net/1128610/) the first error occurs at line 385,
>> >> which is:
>> >>
>> >> ../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string
>> >> literal, format string not checked [-Werror=format-nonliteral]
>> >>        tmplen = strftime (tmpbuf, tmpbufsize, locale_format, &tm);
>> >>        ^~~~~~
>> >>   CC       libglib_2_0_la-gdir.lo
>> >>   CC       libglib_2_0_la-genviron.lo
>> >> cc1: some warnings being treated as errors
>> >> Makefile:1782: recipe for target 'libglib_2_0_la-gdate.lo' failed
>> >> make[4]: *** [libglib_2_0_la-gdate.lo] Error 1
>> >>
>> >> This happens to be a known error/bug (Ref:
>> >> https://bugs.freedesktop.org/show_bug.cgi?id=95326)
>> >> and a patch is available for it here:
>> >>
https://gitlab.gnome.org/GNOME/glib/commit/8cdbc7fb2c8c876902e457abe46ee18a0b134486
>> >>
>> >> Following the patch I manually made changes into
>> >>
'$HOME/quick-start/src/rsb/rtems/build/glib-2.39.3-x86_64-linux-gnu-1/glib-2.39.3/glib/gdate.c'
>> >>
>> >> But the problem is that as soon as I run
>> >> `../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> >> devel/qemu.bset`
>> >> My manual changes to the gdate.c disappear and I get the same error as
>> >> before. I don't know what is going on.
>> >>
>> > I applied the patch that you found along with another patch and built
the souces, glib built
>> > successfully, but unfortunately the couverture-qemu itself failed to
build. Here's the log:
>> > https://paste.ofcode.org/KmJCNZrJyQNev6R4FSUafe
>> >
>> > Here I'm pasting the diff to add patches to RSB:
>> > ```
>> > diff --git a/bare/config/devel/glib-2.39.3-1.cfg
b/bare/config/devel/glib-2.39.3-1.cfg
>> > index d86fe28..0bada15 100644
>> > --- a/bare/config/devel/glib-2.39.3-1.cfg
>> > +++ b/bare/config/devel/glib-2.39.3-1.cfg
>> > @@ -14,6 +14,10 @@
>> >
>> >  %hash sha256 glib-%{glib_version}.tar.xz
d9fa6c9aa645a5e688a3bb29013bb83801b19ee767d99e33ff52e004e1cc5fc8
>> >
>> > +#Patch to supress string literal warning
>> > +
>> > +%patch add glib
https://gitlab.gnome.org/GNOME/glib/commit/0817af40e8c74c721c30f6ef482b1f53d12044c7.patch
>> > +%patch add glib
https://gitlab.gnome.org/GNOME/glib/commit/566e1d61a500267c7849ad0b2552feec9c9a29a6.patch
>> >  #
>> >  # The GLib build instructions. We use 2.x.x Release 1.
>> >  #
>> > ```
>> >
>> > You can apply the above diff into your rtems-source-builder and try to
build couverture qemu.
>> > Most likely it will fail it seems.
>> >>
>> >>
>> >> After this I found out that `qemu4.bset` is also present so I ran
>> >> $ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> >> devel/qemu4.bset
>> >>
>> >> It seems to have run successfully here is the full output:
>> >> https://paste.debian.net/1128611/
>> >>
>> >> Seems like qemu-system-sparc is now installed. But still while running
>> >>
>> >> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
>> >> --log=coverage_analysis.log --no-clean --coverage=score
>> >> --rtems-bsp=leon3-qemu-cov
>> >>
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
>> >>
>> >> I get the same error related to qemu-system-sparc.
>> >> Here is the full output: https://paste.debian.net/1128612/
>> >>
>> >> But this time there is a little difference.
>> >> Earlier it exited with exit code 2. see (
https://paste.debian.net/1128608/)
>> >> Now it is exiting with exit code 1. see (
https://paste.debian.net/1128612/)
>> >> Note: To see the exit code on the above 2 links you may have to use
>> >> the horizontal scroll.
>> >>
>> >> What am I doing wrong ? Please suggest a way to solve this. I am just
>> >> trying to run a simple rtems-test coverage.
>> >
>> > For now, I suggest you to use --rtems-bsp=leon3-sis-cov instead of
qemu,
>> > this is give you the reports and you can start focusing on your main
ticket.
>> >
>>
>>
>> Thanks for the suggestion, leon3-sis-cov works, with a minor error as:
>>
>> error: copying tree (4):
>> /home/user45/quick-start/rtems/5/share/rtems/tester/covoar/covoar.css
>> -> /home/user45/quick-start/leon3-sis-coverage/score: [Errno 2] No
>> such file or directory:
>> '/home/user45/quick-start/rtems/5/share/rtems/tester/covoar/covoar.css'
>>
> This was fixed a few days ago. Please update to the current HEAD of
rtems-tools and
> do a `./waf clean build install`
>>
>> But the leon3-sis-report.html gives the coverage report. I am still
>> studying the leon3-sis-coverage directory.
>>
> Great!
> After updating the rtems-tools, go for a full samples directory run.
> (just replace the /path/to/samples/hello.exe in your command with
/path/to/samples/ )
>


I am trying to understand ticket #3515
https://devel.rtems.org/ticket/3515

So I ran the below commands.

$ rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
--log=coverage_analysis.log --no-clean --coverage=score
--rtems-bsp=leon3-sis-cov
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe

$ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -vvvv -S
/home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
-O leon3-sis-coverage -E
/home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
-p RTEMS-5
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe

The Output is at: https://gofile.io/?c=xQKwul

#3515 says that the covoar fails for fstests/fsclose01.exe
Although I do not understand the output entirely but it looks as if covoar
on fstests/fsclose01.exe did not fail because when I run covoar on
samples/hello.exe the output is similar.

The content of leon3-sis-coverage/ExplanationsNotFound.txt:
coremsg.c:86
schedulerpriorityyield.c:47
schedulerpriorityyield.c:51
schedulerpriorityyield.c:52

The strange part is line 86 in
quick-start/src/rtems/cpukit/score/src/coremsg.c is a comment.

And there is no line 47,51,52 in
quick-start/src/rtems/cpukit/score/src/schedulerpriorityyield.c

Do these numbers not represent line numbers ? If not, what do they
represent ?

What am I missing here ?
What counts as covoar getting failed ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200204/71e5f9c7/attachment-0001.html>


More information about the devel mailing list