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

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Mon May 21 15:13:55 UTC 2018 

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

>
>
> 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.
>
>
I saw the other thread . In sparc I'm getting CSWTCH.* in local text
segment "t" .

[lunatic at lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep -i csw
40010c18 t CSWTCH.1

I followed the INFO messages for a mismatch in
_Workspace_Allocate_or_fatal_error

here's what I came up with

--------------- capture.exe
[lunatic at lunatic samples]$ sparc-rtems5-objdump -d capture/capture.exe |
grep "_Workspace_Allocate_or_fatal_error"
40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_error>
400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_error>
40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_error>
40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_error>
4001628c <_Workspace_Allocate_or_fatal_error>:
400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_error+0x30>
4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_error>

-------------- base_sp.exe
[lunatic at lunatic samples]$ sparc-rtems5-objdump -d base_sp/base_sp.exe |
grep "_Workspace_Allocate_or_fatal_error"
40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_error>
400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_error>
40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_error>
4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_error>
4000c58c <_Workspace_Allocate_or_fatal_error>:
4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_error+0x30>


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

More information about the devel mailing list