On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee < vijaykumar9...@gmail.com> wrote:
> 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 . > I'm building sparc now. What mismatches do you see? I started another thread for CSWTCH.*. That's not the type of mismatch Cillian worked on last summer. It is a symbol that isn't even code and shouldn't be in the symbol set. > > 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
