<div dir="ltr">Hi, thanks for all your replies.<div><br><div class="gmail_extra"><div class="gmail_quote">2014-08-14 15:38 GMT+02:00 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 8/13/2014 10:13 PM, Chris Johns wrote:<br>
> On 14/08/2014 7:34 am, Joel Sherrill wrote: </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""></div><div class="">
>> The other part is in covoar itself. As it processes each exe and builds<br>
>> the internal<br>
>> database of information, it needs the physical address of each method of<br>
>> interest<br>
>> in that particular exe. That is done by an invocation of nm with some<br>
>> magic processing<br>
>> afterwards. This could be done with libelf I think.<br>
> The rtl-host is a wrapper to libelf which is included in the rtl-host<br>
> code we are not dependent on host specifics or versions.<br>
</div>Currently covoar uses system() to invoke nm (maybe with a sed) and then<br>
process it<br>
using regular file operations.<br>
<br></blockquote><div><br></div><div>Not exactly, currently there is do_coverage.sh shell script, where nm is invoked and its output is filtered with grep and sed before running covoar. Filtered output is written to text file which is passed to covoar by configuration file.  </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, I don't see much difference between invoking nm and<br>
rtl-host. Either<br>
will require a system and then loading the symbol set from a file. On a<br>
large set<br>
of executables, this may be a large time consumer. It would be better to<br>
directly<br>
use libelf to read the symbols. It should simplify and speed things up.<br>
<div class="">>>> But I also wonder if it would not be better to focus on changing flow<br>
>>> of covoar - to avoid multiple runs (one for each symbol set as it<br>
>>> would be now), because it takes quite long. I think it should be done<br>
>>> in such way, that covoar reads symbol sets configuration file, runs<br>
>>> analysis and takes data for all desired symbols from all sets and<br>
>>> finally performs multiple reporting part, generating simple, generic<br>
>>> output for each symbols set.<br>
>>><br>
>> Then covoar knows what purpose and scope of the reports are.  As it<br>
>> stands now, covoar knows NOTHING<br>
>> about RTEMS. Let's keep it that way.<br>
> Out of interest what is config file format for covoar ? I have added INI<br>
> file support to the rtl-host repo and it seems stable and flexible.<br>
</div>I think it is just name=value without sections. I honestly don't recall<br>
but it is not fancy.<br>
It could easily be switched to .ini. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">>> covoar gets slower as the set of symbols and tests grows. The standard<br>
>> run now already does at<br>
>> least two covoar runs. Once for "all" and one for "core". The build and<br>
>> test execution time dominates.<br>
> Where is bottleneck ? The RTL code uses an STL map for symbol look up.<br>
</div>See above. I think executing nm on each exe with whatever filter<br>
commands and<br>
then reading them. Using libelf directly will help a lot.<br>
<br>
I don't recall any other hot spots but that there are places where you<br>
have to<br>
cycle over all exe's for all symbols of interest. That is obviously<br>
O( num exes * num syms) but I don't think it is the big issue. I think<br>
the first<br>
issue is just like make vs waf. Avoid doing system() and parsing output<br>
files<br>
500 times (# tests) and just read the symbol table directly. That has to<br>
be a<br>
huge time saver<br>
<div class="im HOEnZb">>> As we process smaller sets of symbols, covoar will be faster anyway.<br>
>> Besides, if it is slow enough,<br>
>> eventually we will profile and fix it. :)<br>
>>> Another job I am thinking about doing next is adding more bsps support<br>
>>> for coverage and getting things working on more bsps. This should be<br>
>>> quite simple.<br>
>>><br>
>> This requires the simulator support. But you should be able to do arm<br>
>> and x86 with qemu.<br>
>>> There is still one problem waiting for decision :-) What with rtems<br>
>>> grub boot img for qemu? How should we integrate it into rtems-tools?<br>
>>><br>
>> Chris?<br>
> Ah yes. I think we should download an image from a know spot but I have<br>
> not looked into how to do this with the RSB.<br></div></blockquote><div><br></div><div>Where should I place this image? Is there any RTEMS ftp or something like this where could I put it, or maybe should I just push it to some Dropbox or sth and download it with RSB?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
><br>
> Maybe building grub from source is possible but that can be something<br>
> for another day.<br>
><br>
> Chris<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Joel Sherrill, Ph.D.             Director of Research & Development<br>
joel.sherrill@OARcorp.com        On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
Support Available                <a href="tel:%28256%29%20722-9985" value="+12567229985">(256) 722-9985</a><br>
<br>
</div></div></blockquote></div><br></div></div><div class="gmail_extra">Chris, should I move rtl-host repo into rtems-tools or wait for your action? I need it to get covoar-related work ready to commit. I am now trying to get things working together and would like to prepare patches to show them working on the end of SOCIS period. </div>
</div>