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

[Joel Sherrill]

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?

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?

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