I have filed a ticket with all the information. https://devel.rtems.org/ticket/3515
On Sat, 1 Sep 2018 at 00:35, Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, Aug 31, 2018 at 1:42 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> >> >> On Sat, 1 Sep 2018 at 00:01, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Fri, Aug 31, 2018, 12:44 PM Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> Hello, >>>> I have listed all the specific exes for which covoar fails. >>>> I have observed that covoar fails only for some specific exe for some >>>> symbol-sets, >>>> this was the reason for covoar not completing successfully. If we >>>> exclude these exe, >>>> covoar finishes successfully for the whole testsuites. So the >>>> prolem has become more >>>> specific now, we'll have to investigate for only these exe. >>>> >>>> Here's the list of all the symbol-sets that were failing, along with >>>> the exe files that made them >>>> trip. >>>> >>>> ----------------------- >>>> posix ---- >>>> sptests/spmutex01.exe >>>> fstests/fsclose01.exe >>>> >>>> sapi ---- >>>> sptests/spversion01.exe >>>> >>>> librfs ---- >>>> fstests/mrfs_fserror.exe >>>> fstests/mrfs_fsrdwr.exe >>>> (all fstests/mrfs_*.exe fails) >>>> fstests/fsrofs01.exe >>>> libtests/flashdisk01.exe >>>> >>>> libdevnull ---- >>>> sptests/sp21.exe >>>> psxtests/psxmmap01.exe >>>> tmtests/tm20.exe >>>> >>>> libblock ---- >>>> fstests/fsbdpart01.exe >>>> --------------------- >>>> >>> >>> Thanks. >>> >>> Have you had a chance to try get with catch throw? >>> >> I'm trying it now with posix and fsclose01.exe, here's what I see. >> > > I think we need Chris to wake up and give us some feedback. The throw is > using > rld::error. > > My guess is that something in those executables is not making rld happy. > #4 is the line of the following line of code in covoar.cc: > > // Load the objdump for the symbols in this executable. > objdumpProcessor->load( exe, objdumpFile, err ); > } > > That's the loop loading the executables. Something in each of these exes > is not making the underlying ELF/DWARF code happy. > > Hopefully Chris will wake up fresh on a nice Australian Saturday and > have an answer. :) > > > >> >> ------------------------------------ >> Catchpoint 1 (exception thrown), 0x00007ffff7ad7f51 in >> __cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80, >> tinfo=tinfo@entry=0x488a70 <typeinfo for rld::error>, >> dest=dest@entry=0x40f980 >> <rld::error::~error()>) >> at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:78 >> 78 PROBE2 (throw, obj, tinfo); >> (gdb) bt >> #0 0x00007ffff7ad7f51 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x832c80, >> tinfo=tinfo@entry=0x488a70 <typeinfo for rld::error>, >> dest=dest@entry=0x40f980 <rld::error::~error()>) at >> ../../../../libstdc++-v3/libsupc++/eh_throw.cc:78 >> #1 0x0000000000405926 in Coverage::ExecutableInfo::findCoverageMap >> (this=<optimized out>, symbolName="wait") >> #2 0x000000000041bc1d in >> Coverage::finalizeSymbol(Coverage::ExecutableInfo*, >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> >&, >> std::__cxx11::list<Coverage::ObjdumpProcessor::objdumpLine_t, >> std::allocator<Coverage::ObjdumpProcessor::objdumpLine_t> >) >> () at ../tester/covoar/ObjdumpProcessor.cc:35 >> > #3 0x000000000041c9e6 in >> Coverage::ObjdumpProcessor::load(Coverage::ExecutableInfo*, >> rld::process::tempfile&, rld::process::tempfile&) () >> at /usr/include/c++/8/new:169 >> #4 0x000000000040e058 in covoar(int, char**) () at >> ../tester/covoar/covoar.cc:381 >> #5 0x000000000040bacc in main () at ../tester/covoar/covoar.cc:563 >> #6 0x00007ffff70fd1bb in __libc_start_main (main=0x40b9b0 <main>, >> argc=11, argv=0x7fffffffd4b8, init=<optimized out>, fini=<optimized out>, >> rtld_fini=<optimized out>, stack_end=0x7fffffffd4a8) at >> ../csu/libc-start.c:308 >> #7 0x000000000040c32a in _start () at ../tester/covoar/covoar.cc:593 >> >> ------------------------------------ >> >>> >>>> >>>> On Wed, 22 Aug 2018 at 21:11, Vijay Kumar Banerjee < >>>> vijaykumar9...@gmail.com> wrote: >>>> >>>>> I will send the attachment offlist as it's too big for the list. >>>>> On Wed, 22 Aug 2018 at 21:07, Vijay Kumar Banerjee < >>>>> vijaykumar9...@gmail.com> wrote: >>>>> >>>>>> The coverage for whole testsuite completed successfully, >>>>>> I have attached the zip file here and also included the js and css >>>>>> files in it. >>>>>> >>>>>> coverage didn't complete for the following symbol-set libraries and >>>>>> was returning, >>>>>> covoar error 10 >>>>>> >>>>>> * libsapi.a >>>>>> * libposix.a >>>>>> * librfs.a >>>>>> * libcsupport.a >>>>>> * libdevnull.a >>>>>> * libblock.a >>>>>> >>>>>> >>>>>> On Wed, 22 Aug 2018 at 10:22, Chris Johns <chr...@rtems.org> wrote: >>>>>> >>>>>>> On 22/08/2018 14:41, Joel Sherrill wrote: >>>>>>> > On Tue, Aug 21, 2018, 10:26 PM Chris Johns <chr...@rtems.org >>>>>>> > <mailto:chr...@rtems.org>> wrote: >>>>>>> > >>>>>>> > On 22/08/2018 09:29, Joel Sherrill wrote: >>>>>>> > > On Tue, Aug 21, 2018, 4:05 PM Vijay Kumar Banerjee >>>>>>> > <vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com> >>>>>>> > > <mailto:vijaykumar9...@gmail.com <mailto: >>>>>>> vijaykumar9...@gmail.com>>> wrote: >>>>>>> > > On Wed, 22 Aug 2018 at 01:55, Joel Sherrill < >>>>>>> j...@rtems.org >>>>>>> > <mailto:j...@rtems.org> >>>>>>> > > <mailto:j...@rtems.org <mailto:j...@rtems.org>>> wrote: >>>>>>> > > >>>>>>> > > How long is covoar taking for the entire set? >>>>>>> > > >>>>>>> > > It works great. this is what `time` says >>>>>>> > > -------- >>>>>>> > > real17m49.887s >>>>>>> > > user14m25.620s >>>>>>> > > sys0m37.847s >>>>>>> > > -------- >>>>>>> > > >>>>>>> > > What speed and type of processor do you have? >>>>>>> > > >>>>>>> > >>>>>>> > The program is single threaded so the preprocessing of each >>>>>>> executable is >>>>>>> > sequential. Memory usage is reasonable so there is no swapping. >>>>>>> > >>>>>>> > Running covoar from the command line on a box with: >>>>>>> > >>>>>>> > hw.machine: amd64 >>>>>>> > hw.model: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz >>>>>>> > hw.ncpu: 16 >>>>>>> > hw.machine_arch: amd64 >>>>>>> > >>>>>>> > plus 32G of memory has a time of: >>>>>>> > >>>>>>> > 366.32 real 324.97 user 41.33 sys >>>>>>> > >>>>>>> > The approximate time break down is: >>>>>>> > >>>>>>> > ELF/DWARF loading : 110s (1m50s) >>>>>>> > Objdump : 176s (2m56s) >>>>>>> > Processing : 80s (1m20s) >>>>>>> > >>>>>>> > >>>>>>> > I don't mind this execution time for the near future. It is far >>>>>>> from obscene >>>>>>> > after building and running 600 tests. >>>>>>> >>>>>>> Yeah, there are other things we need to do first. >>>>>>> >>>>>>> > The DWARF loading is not optimised and I load all source line >>>>>>> to address maps >>>>>>> > and all functions rather that selectively scanning for >>>>>>> specific names at the >>>>>>> > DWARF level. It is not clear to me scanning would be better or >>>>>>> faster. >>>>>>> > >>>>>>> > I doubt it is worth the effort. There should be few symbols in an >>>>>>> exe we don't >>>>>>> > care about. Especially once we start to worry about libc and libm. >>>>>>> >>>>>>> Yeah, this is what I thought at the start. >>>>>>> >>>>>>> > My hope >>>>>>> > is moving to Capstone would help lower or remove the objdump >>>>>>> overhead. Then >>>>>>> > there is threading for the loading. >>>>>>> > >>>>>>> > > I don't recall it taking near this long in the past. I used >>>>>>> to run it as >>>>>>> > part of >>>>>>> > > development. >>>>>>> > >>>>>>> > The objdump processing is simpler than before so I suspect the >>>>>>> time would have >>>>>>> > been at least 4 minutes. >>>>>>> > >>>>>>> > > But we may have more tests and the code has changed. >>>>>>> > >>>>>>> > I think having more tests is the dominant factor. >>>>>>> > >>>>>>> > > Reading dwarf >>>>>>> > > with the file open/closes, etc just may be more expensive >>>>>>> than parsing the >>>>>>> > text >>>>>>> > > files. >>>>>>> > >>>>>>> > The reading DWARF is a cost and at the moment it is not >>>>>>> optimised but it is only >>>>>>> > a cost because we still parse the objdump data. I think >>>>>>> opening and closing >>>>>>> > files is not a factor. >>>>>>> > >>>>>>> > The parsing the objdump is the largest component of time. >>>>>>> Maybe using Capstone >>>>>>> > with the ELF files will help. >>>>>>> > >>>>>>> > > But it is more accurate and lays the groundwork.for more >>>>>>> types of analysis. >>>>>>> > >>>>>>> > Yes and think this is important. >>>>>>> > >>>>>>> > +1 >>>>>>> > >>>>>>> > > Eventually we will have to profile this code. Whatever is >>>>>>> costly is done for >>>>>>> > > each exe so there is a multiplier. >>>>>>> > > >>>>>>> > > I suspect this code would parallelize reading info from the >>>>>>> exes fairly well. >>>>>>> > >>>>>>> > Agreed. >>>>>>> > >>>>>>> > Might be a good case for C++11 threads if one of the thread >>>>>>> container classes is >>>>>>> > a nice pool. >>>>>>> >>>>>>> Good idea. I think we need to look at some of the global object >>>>>>> pointers before >>>>>>> we head down this path. >>>>>>> >>>>>>> > And we might have some locking to account for in core data >>>>>>> structures. Are STL >>>>>>> > container instances thread safe? >>>>>>> >>>>>>> We need to manage all locking. >>>>>>> >>>>>>> > But an addition after feature stable relative to old output plus >>>>>>> Capstone. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>> > > Merging the info and generating the reports not well due to >>>>>>> data contention. >>>>>>> > >>>>>>> > Yes. >>>>>>> > >>>>>>> > > But optimizing too early and the wrong way is not smart. >>>>>>> > >>>>>>> > Yes. We need Capstone to be added before this can happen. >>>>>>> > >>>>>>> > +1 >>>>>>> > >>>>>>> > I would also like to see gcov support but that will not be a >>>>>>> factor in the >>>>>>> > performance we have. It will add reading a lot more files (gcno) >>>>>>> and writing a >>>>>>> > lot of gcda at the end. Again more important to be right than fast >>>>>>> at first. And >>>>>>> > completely an addition. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
