[PATCH] covoar.cc: Correct build path checks for multiple executables.
Cillian O'Donnell
cpodonnell8 at gmail.com
Mon May 21 20:13:06 UTC 2018
Yeah I can see the difference in the objdump, it's optimized out though, so
not very helpful but the addresses do match the covoar output. That's with
-O2. I'll have to rebuild. Vijay you seeing the ... optimized out stuff
*********************************************************************
13338 4000c5ac <_Workspace_Allocate_or_fatal_error>:
13339 4000c5ac: 9d e3 bf a0 save %sp, -96, %sp
13340 4000c5b0: 96 10 20 00 clr %o3
13341 4000c5b4: 94 10 20 00 clr %o2
13342 4000c5b8: 92 10 00 18 mov %i0, %o1
13343 4000c5bc: 11 10 00 4a sethi %hi(0x40012800), %o0
13344 4000c5c0: 7f ff e9 bf call 40006cbc
<_Heap_Allocate_aligned_with_bounda ry>
13345 4000c5c4: 90 12 22 a0 or %o0, 0x2a0, %o0 ! 40012aa0
<_Workspace_Area>
13346 4000c5c8: 80 a2 20 00 cmp %o0, 0
13347 4000c5cc: 02 80 00 04 be 4000c5dc
<_Workspace_Allocate_or_fatal_error+0 x30>
13348 4000c5d0: b0 10 00 08 mov %o0, %i0
13349 4000c5d4: 81 c7 e0 08 ret
13350 4000c5d8: 81 e8 00 00 restore
13351 4000c5dc: 7f ff eb 5f call 40007358 <_Internal_error>
13352 4000c5e0: 90 10 20 03 mov 3, %o0
13353 4000c5e4: 01 00 00 00 nop
13354 ...
13355
13356 4000c600 <syscall>:
************************************************************************
**************************************************************************
23776 400162ac <_Workspace_Allocate_or_fatal_error>:
23777 400162ac: 9d e3 bf a0 save %sp, -96, %sp
23778 400162b0: 96 10 20 00 clr %o3
23779 400162b4: 94 10 20 00 clr %o2
23780 400162b8: 92 10 00 18 mov %i0, %o1
23781 400162bc: 11 10 00 d1 sethi %hi(0x40034400), %o0
23782 400162c0: 7f ff e5 32 call 4000f788
<_Heap_Allocate_aligned_with_bounda ry>
23783 400162c4: 90 12 22 20 or %o0, 0x220, %o0 ! 40034620
<_Workspace_Area>
23784 400162c8: 80 a2 20 00 cmp %o0, 0
23785 400162cc: 02 80 00 04 be 400162dc
<_Workspace_Allocate_or_fatal_error+0 x30>
23786 400162d0: b0 10 00 08 mov %o0, %i0
23787 400162d4: 81 c7 e0 08 ret
23788 400162d8: 81 e8 00 00 restore
23789 400162dc: 7f ff e7 1c call 4000ff4c <_Internal_error>
23790 400162e0: 90 10 20 03 mov 3, %o0
23791 400162e4: 01 00 00 00 nop
23792
23793 400162e8 <rtems_shell_wait_for_explicit_input>:
*********************************************************************
On 21 May 2018 at 20:12, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:
> On 22 May 2018 at 00:33, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> 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.
>>>
>>
>> Are you sure those are the two executables which it is tripping over?
>>
> they were the first two in the list . seems like there are other exes
> having conflict with base_sp in other symbols.
>
> have a look
> =================================================
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for hex2ascii_data with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/41 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/49)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Thread_queue_Operations_default with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/356 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/352)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for CSWTCH.1 with different sizes (/home/lunatic/development/
> rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe/32
> != /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/756)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/80)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for CSWTCH.1 with different sizes (/home/lunatic/development/
> rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe/756
> != /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/12)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/fileio/fileio.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
> =====================================================
>
>
>> I have never seen a case where the code matched by hand and covoar messed
>> up. But there is always the first. :)
>>
>> I can look into it in more detail with some instructions as I'm clueless
> myself.
>
>
>> Are you running with just those two executables?
>>
>> I'm running with all the samples/
>
>> If the input Is the same and covoar doesn't believe it, then gdb is your
>> friend. Or you will have to add some helpful verbose messages that Cillian
>> and I couldn't.
>>
>> I don't yet understand it clearly. It surely needs some more messages.
>
> Is it only me with these messages ?
>
>>
>>
>>>>> 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
>>>
>> Change them by hand in the .cfg file for now.
>>
>> Okay, Thanks.
>
>>
>> Changege them -joelel
>>
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 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/158c3531/attachment-0002.html>
More information about the devel
mailing list