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

[Cillian O'Donnell]

On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
wrote:

> 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 ?
>

It'll be a sparc-objdump that was built with the rsb in 5/bin/. I'm not
sure if we're still grabbing the objdump using rtems-tools now, so not 100%
sure that this still the way to investigate this.

>
> 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 is different in that it's just allowing the user an easier way of
choosing the right ini. So it wouldn't be a dependency like the other
thing, if you run it manually you will still have to select the ini you
want. So this will be part of the script.

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