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

Mon May 21 14:52:30 UTC 2018

On 21 May 2018 at 17:39, Joel Sherrill <joel at rtems.org> wrote:

> CPU-rtems5-objdump
>
> sparc-rtems5-objdump worked  , thanks .
I can see some mismatches in the disassembly .

Probably i386. Aren't you running pc386?
>
> I'm running sparc

> Not sparc/erc32 or Leon
>
> On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell <cpodonnell8 at gmail.com>
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> On 21 May 2018 at 16:39, Cillian O'Donnell <cpodonnell8 at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, <cpodonnell8 at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>> can't run sparc-objdump.
>>>
>>
>> That might not be the exact name. Is there something that looks like it
>> in that directory.
>>
>>> Sorry *rtemstoolkit
>>>>
>>>>> 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.
>>>>>
>>>> Oh , I will look into this then. :)
>>>
>>>> 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/920f2c3e/attachment-0001.html>