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

Joel Sherrill joel at rtems.org
Mon May 21 17:37:41 UTC 2018 

On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

> On 21 May 2018 at 21:42, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> 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" .
>>>
>>
>> Grr... this may require us to toss out some symbol patterns that are
>> generated
>> by GCC.
>>
>>
>>>
>>> [lunatic at lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep
>>> -i csw
>>> 40010c18 t CSWTCH.1
>>>
>>
>> I see this also on the sparc. On the i386, it is rodata.
>>
>>
>>>
>>> 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>
>>>
>>
>> That shows the references to the symbol not the size. You need to look at
>> the start of
>> the symbol and start of the following symbol.
>>
>> I looked at the "nm -N" output for base_sp.
>>
>> 0200ba0c T _Workspace_Allocate_or_fatal_error
>> 0200ba48 T _SPARC_Counter_read_address
>>
>> I get this for base_sp
> 4000c58c T _Workspace_Allocate_or_fatal_error
> 4000c5e0 T syscall
>
> 0xe0 - 0x8c = 0x54 ==> 84
>
>
>> And for capture:
>>
>> 02015c3c T _Workspace_Allocate_or_fatal_error
>> 02015c78 T rtems_shell_wait_for_explicit_input
>>
>>  4001628c T _Workspace_Allocate_or_fatal_error
> 400162c8 T rtems_shell_wait_for_explicit_input
>
> 0xc8 - 0x8c = 0x3C ==> 60
>

OK. In base_sp.exe, what is at the end of the method
_Workspace_Allocate_or_fatal_error before the beginning of syscall?

When you compare the code for  _Workspace_Allocate_or_fatal_error in both
.exe files, are they the same? They should be since the code is coming from
a library and it always has matched in the past. But...


>
> base_sp: 0x48 - 0x0c = 0x3C ==> 60
>> capture: 0x78 - 0x3c = 0x3c ==> 60
>>
>> Based on that alone, they are the same size. Now let's look at the
>> objdump and see what's
>> at the end that might look like padding:
>>
>> base_sp.exe ========================
>>     _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>  200ba3c:       7f ff ea d4     call  200658c <_Internal_error>
>>  200ba40:       90 10 20 03     mov  3, %o0
>>  200ba44:       01 00 00 00     nop
>> ====================================
>>
>> The nop would be considered padding by covoar since it is at the end of
>> the method.
>>
>> capture.exe ===========================
>>
>>     _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>  2015c6c:       7f ff e6 53     call  200f5b8 <_Internal_error>
>>  2015c70:       90 10 20 03     mov  3, %o0
>>  2015c74:       01 00 00 00     nop
>>
>> ====================================
>>
>> Comparing the body of the two methods based on objdump output, I don't
>> see any difference for sparc/erc32 at -O2.
>>
>> I repeated looking at the objdump output at -Os and they were the same
>> instructions
>> and length.
>>
>> You will have to investigate to see why they are different on your side.
>>
>> What am I doing different ? Is it because of the covoar patches ?
> (have you applied the patches ?)
>

I got my results comparing the .exe's by hand with no involvement of covoar.

What compiler flags are you using? -O2 or -Os? Gcov arguments? Any other
changes to them?


> --joel
>>
>>
>>
>>
>>
>>>
>>>
>>>>> 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/42fb2686/attachment-0002.html>

More information about the devel mailing list