On Tue, 4 Feb 2020 at 13:28, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> wrote:
> > > On Tue, Feb 4, 2020, 11:33 AM Bran S <archsb...@gmail.com> wrote: > >> On Saturday, 1 February 2020, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> > >> > >> > >> > On Sat, Feb 1, 2020 at 9:31 PM Bran S <archsb...@gmail.com> wrote: >> >> >> >> On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >> > >> >> > On Sat, Feb 1, 2020 at 12:57 PM Bran S <archsb...@gmail.com> wrote: >> >> >> >> >> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns <chr...@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. > Command: $ /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 Output: ... error: ExecutableInfo::findCoverageMap: wait Found findCoverageMap in /home/user45/quick-start/src/rtems-tools/tester/covoar/ExecutableInfo.cc:124 If I want to make some changes into the file, how to make those changes, to take effect ? I should mention that the covoar binary used in the command above was not created via rtems-tools repository directly. It was built according to the instructions in the quick-start guide.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
