[PATCH] covoar.cc: Correct build path checks for multiple executables.

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Fri May 18 22:24:25 UTC 2018


On 19 May 2018 at 03:29, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
> vijaykumar9597 at gmail.com> wrote:
>
>>
>>
>> On Sat, 19 May 2018, 03:06 Joel Sherrill, <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
>>> vijaykumar9597 at gmail.com> wrote:
>>>
>>>> On 19 May 2018 at 02:29, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com
>>>> > wrote:
>>>>
>>>>> On 19 May 2018 at 01:30, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 18 May 2018 at 19:09, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18 May 2018 at 12:30, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Cool, you should run it for the full testsuite and take a look at
>>>>>>>>>> that report (takes a while.. around 575 tests)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> When I try to run the full testsuites it gives the following
>>>>>>>>> error . What could be causing this ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you run the full testsuite without the coverage options, does it
>>>>>>>> still happen?
>>>>>>>>
>>>>>>> No it seems to run fine without coverage.
>>>>>>>
>>>>>>
>>>>>> I vaguely remember seeing this before last year, I suspect that when
>>>>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>>>>> about it for now, carry on with what you're doing. What branch are you
>>>>>> working on at the moment?
>>>>>>
>>>>> The path to build directory from the executable path is working now !
>>>>>
>>>>> I'm working in this branch currently, I'll send a patch to all of it
>>>>> together when it starts working.
>>>>>
>>>> I meant to say once the parsing of ini file starts working. the path to
>>>> build directory is already working.
>>>>
>>>>> Please have a look and also suggest improvements where applicable .
>>>>>
>>>>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>>>>
>>>>> after this update, running it on full testsuits doesn't give that
>>>>> error anymore but it has some other issue. The report doesn't shows data
>>>>> only for samples even after running it for full testsuites
>>>>>
>>>>
>>> Do you have coverage output on all the tests?
>>>
>> I have coverage output on tests under samples/ only .
>> running it for the whole testsuits gives the same coverage output as with
>> samples/
>>
>>>
>>> Is the verbose output indicating that all the tests are being looped
>>> over?
>>>
>>>
>>>>
>>>>> and I'm getting this error :
>>>>>
>>>>> -----
>>>>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>>>>
>>>>
>>>
>>> Cillian must want to purge all memory of this type of message. :)
>>>
>>> This message indicates that a symbol of interest (e.g. a function) has
>>> one length
>>> in one executable file and a completely different one in a second.
>>> Cillian worked
>>> on one of these last summer which was because the method was padded with
>>> a different number of nops in each executable. That was supposed to be
>>> handled
>>> by covoar but he found a nasty bug.
>>>
>>> This particular one looks like it is for a GCC generated symbol which
>>> should
>>> have been ignored in the symbols of interest. My bet is that the way we
>>> formerly
>>> got the DesiredSymbols only got real methods. The new way must also be
>>> picking up some "local" symbols that gcc is generating.
>>>
>>> If we know either of those executables, we should be able to look at the
>>> symbol table with nm and figure out what Chris is pulling in that he
>>> shouldn't.
>>>
>>> Is this a fatal error or just a "give up" on this symbol in this
>>> executable?
>>>
>> it doesn't break in the middle. Coverage does run but the report doesn't
>> look proper
>>
>
> This is an auto-generated symbol by gcc which will be in the middle of a
> method.
> DesiredSymbols should be ignoring symbols like this. I don't think seeing
> them
> will cause a horrible problem but it is quite likely that the method(s)
> these are
> seen in will have quite incorrect results.
>
> If running on samples looks OK, try running coverage from just tmtests and
> see if that is better. You need to find a set small enough to trip the
> problem
> but easy to analyse.
>
Coverage from tmtests looks OK .
psxtmtests , psxtests, libtests gives the same error and doesn't show
proper coverage report.

Also, I can see these INFO lines even with the ones that are showing proper
coverage output

--------------
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
hex2ascii_data because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
hex2ascii_data because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
hex2ascii_data because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Workspace_Allocate_or_fatal_error because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
hex2ascii_data because the sizes are different
Coverage run for score finished successfully.
-----------------------------------------------


> --joel
>
>
>>
>>> --joel
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20180519/988882be/attachment.html>


More information about the devel mailing list