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
