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

Mon May 21 15:07:16 UTC 2018

On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

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

I'm building sparc now. What mismatches do you see?

I started another thread for CSWTCH.*. That's not the type of mismatch
Cillian
worked on last summer. It is a symbol that isn't even code and shouldn't be
in the symbol set.

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