Re: Ticket #3515: covoar failure while running for full testsuites
HI I don't have an immediate answer but I have questions. + Is wait() in the Symbol Set the coverage analysis is supposed to include? If so, this error is a side-effect of a normal execution case which shouldn't be an error. We are careful that an RTEMS exe only includes the minimum symbols needed. This means that if a symbol is not needed, the linker leaves it out. covoar is going to ask for information in the exe for every symbol of interest and some/many will not be in a particular exe. It should just ignore the "symbol not found in this exe" reported by the symbol lookup. There is a bit of a degenerate case where the symbol is not in any exe. This means that covoar has never actually seen an exe with the code in it and thus cannot include it in the coverage reports. There is a special report for methods with 0 coverage. They are just listed by name. + If wait() is not in the "symbols of interest", then I have no idea why covoar is looking for it in the exe. If it's the first case, then I expect integrating the new-ish use of the ELF/DWARF library rather than executing nm and parsing the output just missed this and whoever did it thought it was an error. --joel --joel On Wed, Feb 26, 2020 at 1:06 AM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > > > On Wed, Feb 26, 2020 at 12:28 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> >> On Fri, Feb 21, 2020 at 1:27 PM Bran S wrote: >> >>> 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. >>> >>> Hi Bran, >> >> Sorry, I couldn't find time to look into the details and I was hoping >> someone >> else will join in. You are in the right direction and found the function >> that is >> getting the error. Now that you have a function to follow, I will suggest >> you to >> run gdb on covoar and follow this function, especially where it's getting >> the >> symbols. >> To run covoar on gdb
Re: Ticket #3515: covoar failure while running for full testsuites
On Wed, Feb 26, 2020 at 12:28 PM Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote: > > > On Fri, Feb 21, 2020 at 1:27 PM Bran S wrote: > >> 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. >> >> Hi Bran, > > Sorry, I couldn't find time to look into the details and I was hoping > someone > else will join in. You are in the right direction and found the function > that is > getting the error. Now that you have a function to follow, I will suggest > you to > run gdb on covoar and follow this function, especially where it's getting > the > symbols. > To run covoar on gdb do the following: > $gdb /path/to/covoar > (gdb) r - -S > /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini > \ > -O leon3-qemu-coverage \ > -E > /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt > \ > -p RTEMS-5 /your/exe.exe > > The above is just an example and you can adapt it according to your exe and bsp. Also, since you're using leon3-sis-coverage, please also add the option -fTSIM > set a breakpoint at findCoverageMap() and see what it is doing. > Most likely, you'll be able to see where is it getting other symbols > from and why is "wait" not there, or if it's there, why is it skipping it. > > Best regards, > Vijay > >> 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
Re: Ticket #3515: covoar failure while running for full testsuites
On Fri, Feb 21, 2020 at 1:27 PM Bran S wrote: > 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. > > Hi Bran, Sorry, I couldn't find time to look into the details and I was hoping someone else will join in. You are in the right direction and found the function that is getting the error. Now that you have a function to follow, I will suggest you to run gdb on covoar and follow this function, especially where it's getting the symbols. To run covoar on gdb do the following: $gdb /path/to/covoar (gdb) r - -S /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini \ -O leon3-qemu-coverage \ -E /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt \ -p RTEMS-5 /your/exe.exe set a breakpoint at findCoverageMap() and see what it is doing. Most likely, you'll be able to see where is it getting other symbols from and why is "wait" not there, or if it's there, why is it skipping it. Best regards, Vijay > 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
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
Re: Ticket #3515: covoar failure while running for full testsuites
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. Best regards, Vijay > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ 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 >> >> >>
Re: Ticket #3515
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 > >> '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/comm
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 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
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_versi
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
Re: Ticket #3515
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? Chris ___ 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
