CPU-rtems5-objdump Probably i386. Aren't you running pc386?
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
