On 22 May 2018 at 00:33, Joel Sherrill <j...@rtems.org> wrote: > > > On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> On 21 May 2018 at 23:07, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> On 21 May 2018 at 21:42, Joel Sherrill <j...@rtems.org> wrote: >>>> >>>>> >>>>> >>>>> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee < >>>>> vijaykumar9...@gmail.com> wrote: >>>>> >>>>>> On 21 May 2018 at 20:37, Joel Sherrill <j...@rtems.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee < >>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>> >>>>>>>> On 21 May 2018 at 17:39, Joel Sherrill <j...@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@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@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@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 < >>>>>>>>> cpodonne...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, < >>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> On 21 May 2018 at 16:39, Cillian O'Donnell < >>>>>>>>>>> cpodonne...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, < >>>>>>>>>>>> cpodonne...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, < >>>>>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 21 May 2018 at 11:56, Cillian O'Donnell < >>>>>>>>>>>>>> cpodonne...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, < >>>>>>>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 21 May 2018 at 02:29, Cillian O'Donnell < >>>>>>>>>>>>>>>> cpodonne...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, < >>>>>>>>>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee < >>>>>>>>>>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, < >>>>>>>>>>>>>>>>>>> cpodonne...@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). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
