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? 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... > > 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. What compiler flags are you using? -O2 or -Os? Gcov arguments? Any other changes to them? > --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
