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

[Joel Sherrill]

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.

--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/20180518/dd221403/attachment-0002.html>