[PATCH] covoar.cc: Correct build path checks for multiple executables.
Joel Sherrill
joel at rtems.org
Mon May 21 20:12:50 UTC 2018
On Mon, May 21, 2018 at 2:12 PM, 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 ?
>
My Monday morning task was to ask what covoar patches are outstanding
and what rtems-testing branch I should be using to be exactly like you two.
But when you started reporting method size mismatches, I started
investigating
the input to covoar.
Starting another thread.
>
>>
>>>>> 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/94955f78/attachment-0002.html>
More information about the devel
mailing list