[PATCH] covoar.cc: Correct build path checks for multiple executables.
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Mon May 21 18:54:20 UTC 2018
On 21 May 2018 at 23:07, Joel Sherrill <joel at rtems.org> wrote:
>
>
> 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?
>
>
_Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
4000c5bc: 7f ff eb 70 call 4000737c <_Internal_error>
4000c5c0: 90 10 20 03 mov 3, %o0
4000c5c4: 01 00 00 00 nop
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...
>
>
it looks the same though.
>
>> 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.
>
> I am getting the above result by hand. running covoar
shows the same size mismatch that I'm getting by hand
> What compiler flags are you using? -O2 or -Os? Gcov arguments? Any other
> changes to them?
>
>
-O2 . No Gcov arguments or any other changes.
PS: For Gcov I'm actually waiting for the discussion on changing the gcc
flags
> --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/20180522/34275cf0/attachment-0002.html>
More information about the devel
mailing list