Ticket #3515: covoar failure while running for full testsuites

Wed Feb 26 14:13:15 UTC 2020

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 <
vijaykumar9597 at gmail.com> wrote:

>
>
> On Wed, Feb 26, 2020 at 12:28 PM Vijay Kumar Banerjee <
> vijaykumar9597 at gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 21, 2020 at 1:27 PM Bran S <archsbran at gmail.com> wrote:
>>
>>> On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee
>>> <vijaykumar9597 at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Feb 17, 2020 at 12:08 AM Bran S <archsbran at gmail.com> 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 -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 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 -vvvv -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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200226/ffff34d8/attachment.html>