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 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 ?) > --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