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

[Vijay Kumar Banerjee]

On 21 May 2018 at 02:29, Cillian O'Donnell <cpodonnell8 at gmail.com> wrote:

>
>
> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
> wrote:
>
>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <cpodonnell8 at gmail.com>
>>> wrote:
>>>
>>>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>>>> Ahh its nice to see the data back in the reports again. Did you manage to
>>>> track down 2 exes with the mismatch in symbol size?
>>>>
>>> Great! so next is the parsing of the symbol file.
>>> I couldn't manage to track down the mismatch.
>>>
>>> I have pushed these to my master branch.
>>
>> The latest update to cov-tester-support branch (please have a look)
>> parses the symbol-set ini file from the coverage script. The parsing
>> is working but currently it's not generating reports, as covoar
>> needs to be updated .
>>
>
> It's best if covoar reads it's own config file, otherwise it creates a
> dependency on the tester. Scanning over the recent changes to covoar there,
> it looks like it can already handle multiple sets, so the one ini with
> multiple sets in it is the way to go.
>
Okay, Understood.

> Here are the things that I have done and that needs to be
>> done in order to generate reports :
>>
>> I have added a symbol-sets.ini file and parsed it from the coverage
>> script
>> this is how it works :
>>
>>
>>    - The ini file can be updated with all the symbols, separated by ' ,
>>    ' (comma)
>>
>>
> This is the way covoar is actually handling it now. You should test a
> multi set ini and see if that's working.
>
Yeah, I have seen it. will try with multiple sets.

>
>>    -
>>    - The coverages splits them and makes a list of all the sets
>>    -  The respective libraries are parsed from the libraries section.
>>    - It returns a dict with all the symbols and thir resp. library
>>    addresses.
>>    - The library addresses are absolute so it can be run from anywhere
>>    top of build tree is not necessary.
>>
>> This was a good idea but it's just that dependency issue we want to stay
> away from. Covoar has something to find the build directory too, it just
> hasn't been connected up yet, so running it from the top of the build
> directory is ok for the moment.
>

yes it can find the build directory. I was giving it a shot to do it from
the script.

If covoar's standalone working is a necessity then it surely needs to be
working
from covoar and shouldn't depend on the script.

>
> Probably the most pressing thing now is investigating those mismatch in
> symbol size.
>

any advice on where/how to look for it ?

> This way we can parse all the symbols from the same ini file.
>>
>> what needs to be done :
>>
>>    - I have added #FIXME s in the code , those are the small fixes that
>>    would be needed .
>>    - The covoar needs to be updated. My proposal is that we can feed the
>>    parsed  dict to the covoar instead of feeding the symbol file and
>>    letting
>>    covoar parse it ( As I mentioned previously).
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180521/98d01963/attachment-0002.html>