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. > >> 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 < >>>>>>> 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