<div dir="auto">Hit send too soon<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020, 8:59 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020, 8:53 PM <a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a> <<a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><span></span>Thanks joel.</div><div><br></div><div>I google the Couverture-Qemu and find many useful document about rtems test coverage.</div><div>The conventional approach will compile source codes to create *.gcno files. But the Couverture-Qemu method needn't. </div><div>In the final report, the Couverture-Qemu method will create an annotated.html file in which the instructions are listed as "NOT EXECUTED" or executed.</div><div>The main different is only assembly language is used, while the conventional approach will list the souce code in C language.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The reports from covoar include the source code. The reports are from a developer perspective and we haven't had any feedback from iv&v folks.  If the reports don't match what you need, there is always the source code . :)</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">This is an area where feedback, contributions, and supporting developers is really appreciated.</div><div dir="auto"><br></div><div dir="auto">And there is an RSB recipe for couverture qemu which should make it easier to build.</div><div dir="auto"><br></div><div dir="auto">I'd love to see this area of our tooling and ecosystem get love and grow.  :)</div><div dir="auto"><br></div><div dir="auto">--joel</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br></div><hr style="width:210px;height:1px" color="#b5c4df" size="1" align="left">
<div><span><div style="MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><div><a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a></div></div></span></div>
<blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div> </div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style="PADDING-RIGHT:8px;PADDING-LEFT:8px;FONT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BOTTOM:8px;PADDING-TOP:8px"><div><b>From:</b> <a href="mailto:joel@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">Joel Sherrill</a></div><div><b>Date:</b> 2020-10-22 23:49</div><div><b>To:</b> <a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a></div><div><b>CC:</b> <a href="mailto:devel@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">devel</a></div><div><b>Subject:</b> Re: rtems-5.1 source code test coverage failed</div></div></div><div><div><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 22, 2020 at 4:02 AM <a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a> <<a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
<div><span></span>hi, all</div><div>I want test source code coverage in qemu. There are some questions I met.</div><div>1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute.</div><div>2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error ----- File format not ELF or archive. </div><div><br></div><div>Is there a tutorial introducing how to get rtems-5.1 source code test coverage?</div></div></blockquote><div><br></div><div>We don't do coverage that way. Some simulators can directly produce gcov data. </div><div>I think tsim can do that for example.</div><div><br></div><div>gcov foundationally assumes that it can run, collect data, and write it to a file</div><div>at program exit. That model doesn't work on embedded targets. There are </div><div>some write ups on the net of people forcing gcov data to be written sporadically</div><div>and magic to get it off target. But this isn't how RTEMS has done coverage.</div><div><br></div><div>We depend on simulators that write trace logs and a utility called covoar which</div><div>can correlate multiple trace logs with the program executables and product</div><div>a unified report. Remember that the same function may be in two RTEMS</div><div>executables but they will not be at the same physical address. The trace/log</div><div>execution information produced by the simulators will be in terms of which</div><div>physical addresses are executed.</div><div><br></div><div>The RTEMS Tester has support for running coverage and hopefully the</div><div>documentation is good at explaining that. </div><div><br></div><div>The qemu couverture project (a separate repo from regular qemu), sis,</div><div>and tsim all produce trace/coverage info for an executable that covoar</div><div>should be able to process. </div><div><br></div><div>FWIW there is at least one known issue with covoar right now. Sometimes</div><div>the reported size of a method differs between two executables. Historically,</div><div>this has been due to padding after a method so the next adjacent </div><div>method in memory is cache line aligned. covoar will reject information</div><div>when a method has different sizes in different executables. But can</div><div>adjust if it is nop padding to ignore at the end. No one has produced</div><div>a reproducible test case to investigate for this latest one. Given</div><div>two executables where function X appears to be different sizes, it</div><div>is usually easy to see by hand what the program is missing. But you</div><div>need that test case.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>Thank you very much!</div>
<div><br></div><hr style="width:210px;height:1px" color="#b5c4df" size="1" align="left">
<div><span><div style="margin:10px;font-family:verdana;font-size:10pt"><div><a href="mailto:smallphd@aliyun.com" rel="noreferrer noreferrer noreferrer" target="_blank">smallphd@aliyun.com</a></div></div></span></div>
</div>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
</div></div></blockquote>
</div></blockquote></div></div></div>
</blockquote></div></div>