Re: Ticket #3515: covoar failure while running for full testsuites
On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee wrote: > > > > On Mon, Feb 17, 2020 at 12:08 AM Bran S wrote: >> >> Hi Guys, >> > Hi Bran! >> >> I am trying to understand and solve Ticket #3515. >> https://devel.rtems.org/ticket/3515 >> >> $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar - >> -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 of the above command is at: >> https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a >> >> On the last line it can be seen that absence of `wait` symbol causes the >> error. >> >> I made some changes in ExecutableInfo.cc to print out the symbols >> being added into coverageMap. >> Added symbols can be seen from line 636 to 7236 at the above link. >> In those lines we can see that `wait` is not added into coverageMap. >> > Great work in finding the possible issue. >> >> I am new so the only thing I know about covoar is that it does >> coverage analysis. >> Any ideas on how to move further into solving this ? > > I added Chris in CC, he'll be able to tell us where to look for the source > of the error you found. > In general, you can follow covoar.cc file, which has the main `covoar` > function in it. That will be a good starting point. > Yeah, I traversed through the code in covoar.cc It goes something like: In covoar.cc: covar() at line 382: objdumpProcessor->load( exe, objdumpFile, err ); Here, `exe` points to the executableinfo object, the one in which the coverageMap was created via createCoverageMap() Now inside objdumpProcessor->load() at line 301: finalizeSymbol() is called which further calls findCoverageMap() at line 35. This is the point where error occurs, as `wait` symbol is not found. The objdumpProcessor->load() function searches symbols in CoverageMap(via finalizeSymbol()) according to the symbols present in objdump generated at line 291: getFile( executableInformation->getFileName(), objdumpFile, err ); The objdump is created using the executableinfo from which we loaded the symbols into CoverageMap, right ? Then is it so that the code missed out on the symbol while adding them into CoverageMap ? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Ticket #3515: covoar failure while running for full testsuites
Hi Guys, I am trying to understand and solve Ticket #3515. https://devel.rtems.org/ticket/3515 $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar - -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 of the above command is at: https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a On the last line it can be seen that absence of `wait` symbol causes the error. I made some changes in ExecutableInfo.cc to print out the symbols being added into coverageMap. Added symbols can be seen from line 636 to 7236 at the above link. In those lines we can see that `wait` is not added into coverageMap. I am new so the only thing I know about covoar is that it does coverage analysis. Any ideas on how to move further into solving this ? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Ticket #3515
On Tue, 4 Feb 2020 at 13:28, Vijay Kumar Banerjee wrote: > > > On Tue, Feb 4, 2020, 11:33 AM Bran S wrote: > >> On Saturday, 1 February 2020, Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> > >> > >> > >> > On Sat, Feb 1, 2020 at 9:31 PM Bran S 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 wrote: >> >> >> >> >> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns 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 >> >> >>
#1977 mq_open lacks support of "mode" argument
Trying to solve ticket https://devel.rtems.org/ticket/1977 The mode parameter sets access permissions for the created message queue. Examples: S_IRUSR 00400 user has read permission S_IWUSR 00200 user has write permission S_IXUSR 00100 user has execute permission Complete list is at: http://man7.org/linux/man-pages/man2/open.2.html https://github.com/RTEMS/rtems/blob/master/cpukit/posix/src/mqueueopen.c#L176 Is this is the place where we need to take care of the mode argument ? I am thinking we would need to store the mode bits in POSIX_Message_queue_Control structure.(Ref: https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems/posix/mqueue.h#L57) Then every time the created queue is accessed we would use the mode bits to check if the accessor is allowed to access the queue. Please share your thoughts on solving this. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Ticket #3515
On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee wrote: > > On Sat, Feb 1, 2020 at 12:57 PM Bran S wrote: >> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns 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, ); >>^~ >> 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 >
Re: Ticket #3515
On Thu, 30 Jan 2020 at 05:52, Chris Johns 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? 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' 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 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, ); ^~ 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. 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Ticket #3515
Hi Guys, I am trying to solve #3515 https://devel.rtems.org/ticket/3515 For this issue covoar is required. So I cloned 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 ? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: #2920 -> #3515
On Tue, 28 Jan 2020 at 23:17, Joel Sherrill wrote: > >> >> Then I ran `hello.exe` using the command `sparc-rtems5-gdb hello.exe` >> inside gdb. >> But when I did `target sim` it displayed (Undefined target command: "sim") >> As a workaround, using `sparc-rtems5-sis` to run hello.exe worked. >> As mentioned in getting started section I have made changes to the >> hello.c file and they are working fine. > > > Can you post a link to the offending content? Or file a ticket? https://paste.debian.net/1128104/ > > sis was recently split out of gdb and is a standalone simulator that > supports SPARC and RISC-V. It is quite improved as a simulator but > RTEMS documentation has always (since 1995) used it as the easiest > BSP to run code for. So there are potentially many places this is described > that are now out of date for the master. > > I had to update the RTEMS class I teach to show how it used to be and how it > is now. > >> >> >> Now regarding #3515: >> For covoar: I cloned 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 ? > > > I'm leaving this one to someone else. > >> >> >> Two more queries: >> 1) rtems-test is also present in the tool-suite, at >> $HOME/quick-start/rtems/5/bin >> Running `rtems-test` in the tool-suite also gives the same error >> of RTEMS toolkit python wrapper not found. >> Are these two rtems-test scripts (this one and the one in >> rtems-tools) same or different ? > > > One is the binary before it is installed. The one in > $HOME/quick-start/rtems/5/bin > is the installed copy. >> >> >> 2) Same is the case for covoar. It is present at both places >> '$HOME/quick-start/rtems/5/share/rtems/tester/bin/covoar' and also >> inside rtems-tools. > > > Ditto >> >> >> Does this mean that rtems-tools is not required ? > > > It does include tools related to the dynamic loading which would be > required to build the RTEMS tests. If you run tests by hand, then > you won't need rtems-tester. > > Most of the contents of rtems-tools will be needed in a normal > workflow. Likely not covoar unless you work with coverage. > #3515 is about covoar. So I guess I would need it. For now I need to find the solution to that python wrapper error above. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
#2920 -> #3515
Hi Guys, I am new to rtems. Looking to solve some issues to get familiar with the project. While going through the ticket list I found issue #3515. I would like to solve this. Background Work: Following the quick-start guide I have built rtems5 and rsb. Ran the 600 tests on BSP erc32 of which 5 tests failed, namely: dl06.exe dl09.exe terminos09.exe psxfenv01.exe psxmsgq03.exe Then I ran `hello.exe` using the command `sparc-rtems5-gdb hello.exe` inside gdb. But when I did `target sim` it displayed (Undefined target command: "sim") As a workaround, using `sparc-rtems5-sis` to run hello.exe worked. As mentioned in getting started section I have made changes to the hello.c file and they are working fine. Now regarding #3515: For covoar: I cloned 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 ? Two more queries: 1) rtems-test is also present in the tool-suite, at $HOME/quick-start/rtems/5/bin Running `rtems-test` in the tool-suite also gives the same error of RTEMS toolkit python wrapper not found. Are these two rtems-test scripts (this one and the one in rtems-tools) same or different ? 2) Same is the case for covoar. It is present at both places '$HOME/quick-start/rtems/5/share/rtems/tester/bin/covoar' and also inside rtems-tools. Does this mean that rtems-tools is not required ? Thanks, -Bran ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
