Ticket #3515

[Vijay Kumar Banerjee]

On Thu, Feb 6, 2020, 7:52 PM Bran S <archsbran at gmail.com> wrote:

> 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
>
> Looks like you spotted the error.

> 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 ?
>
after making the changes in rtems-tools, build it with `./waf build
install`

> 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.
>
That's alright, but after making the changes, you must build rtems-tools
for the changes to
take effect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200207/c45358f2/attachment.html>