Ticket #3515: covoar failure while running for full testsuites

[Vijay Kumar Banerjee]

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 ?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200226/b8c57898/attachment-0001.html>