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