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