<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">smallphd@aliyun.com</a> <<a href="mailto:smallphd@aliyun.com">smallphd@aliyun.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>
<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:1px solid 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" target="_blank">smallphd@aliyun.com</a></div></div></span></div>
</div>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>