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" .
[lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep -i csw 40010c18 t CSWTCH.1 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> >> 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
