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 <vijaykumar9...@gmail.com> wrote: > 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
