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