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/ ) > On a sidenote I see that you worked on this as your gsoc project. > Please mention any source which proved to be helpful in understanding > rtems better. > docs (docs.rtems.org) is the best place to know about rtems and in case of any doubt, you can always post to the users@ and devel@ lists, the community is very helpful and welcoming :) Also, for coverage analysis, the wiki page that you found, has almost all the information that I could collect regarding stuff related to rtems coverage analysis. You won't need so much detailed theory to start the project. Your main focus for ticket #3515 is how the tools are generating the reports. You'll soon have to dive into covoar/ to figure out where it's causing the problem. For individually running the exe files in covoar, you can use the command for covoar which is noted on the ticket page of #3515. Best regards, Vijay
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel