Ticket #3515
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Tue Feb 4 07:58:39 UTC 2020
On Tue, Feb 4, 2020, 11:33 AM Bran S <archsbran at gmail.com> wrote:
> 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
>
The command is correct but it's running coverage for "score" only.
The --coverage option, if added without any argument, will run the coverage
analysis of the exe for all the subsystems (like score, posix, rtems etc.)
>From the ticket: It looks like covoar is failing for fsclose01.exe under
posix.
To test that, you can either just add --coverage option without any
argument and wait for it to fail in posix, or you can just add
--coverage=posix since we just want to check posix.
>
> $ /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 ?
>
The do represent line numbers and it looks like you found some discrepancy.
I would suggest you to try some other combinations of exe and subsystems to
see if you find any pattern. This will help you understand if it's only
with these exes or is this a problem in general.
>
> What am I missing here ?
>
Mentioned above.
> What counts as covoar getting failed ?
It'll return error.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200204/037181f9/attachment-0001.html>
More information about the devel
mailing list