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