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

[Vijay Kumar Banerjee]

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

>
>
> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
> wrote:
>
>> 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.
>>
>
> It should be working from covoar and it will.
>
>>
>>> Probably the most pressing thing now is investigating those mismatch in
>>> symbol size.
>>>
>>
>> any advice on where/how to look for it ?
>>
>
> Before what I was doing was examining the objdump of 2 exes, looking there
> on the weekend i think the info messages mentioned which ones were having
> trouble for which symbol. It says something like "couldn't merge coverage
> map for some_symbol because sizes from exe != to size of other_exe. Look at
> the objdump of exe and other_exe, search for some_symbol and compare the
> dissasembly. There'll be more lines in one than the other, nop padding
> probably. Then you had to find a check that was strict enough to chop the
> end of the symbol in question at the right place but not so strict that it
> chopped other symbols in the wrong place. However the method of obtaining
> the symbols has changed, I'll have to have a look over the covoar changes
> tonight to see what would be the equivalent method of checking this now.
> Unless Chris or Joel come back with the answer before then.
>
> Please have a look into this as I'm confused .
>From the messages it seems like there's something with
the base_sp.exe .
I tried to run objdum with -d , I'm getting an error
objdump: can't disassemble for architecture UNKNOWN!
what am I missing ?

Also there will probably be multiple ini's with different collections of
> sets that the user could run so it would be good to give them some method
> of choosing which ini they want, like coverage=score will feed score.ini to
> covoar. You could try have a go at that.
>

yeah I was planning something similar with the script
to let users  choose the sets, and run all by default .
I guess it needs to be done from covoar to avoid dependancy.
I can have look into this.

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