Using rtl-host in covor - some questions

Chris Johns chrisj at rtems.org
Thu Aug 14 03:13:28 UTC 2014


On 14/08/2014 7:34 am, Joel Sherrill wrote:
>
> On 8/13/2014 3:49 PM, Krzysztof Mięsowicz wrote:
>> Hi,
>>
>> Thanks for your replies :-) I didn't see librld.a because I had old
>> version of repo and after updating it appears :-)
>>
>> I think for now it would be better to get everything integrated with
>> old "nm-based" approach. I had it working as a separate module, now I
>> will integrate it into covoar. I think that one of next steps may be
>> generating symbols without nm.
>>
> There are two uses of symbols in covoar.
>
> The first is external and it is generating the "symbols of interest" for
> the run. That
> is currently a process that runs over the set of libraries of interest
> and lists all the
> text symbols in those libraries. Doing that with the Python based code
> should be a
> snap.
>

What does "run over a set of libraries" mean ?

We have a really good way to get at the symbols via C++ now with 0 
parsing code or external tools.

> The other part is in covoar itself. As it processes each exe and builds
> the internal
> database of information, it needs the physical address of each method of
> interest
> in that particular exe. That is done by an invocation of nm with some
> magic processing
> afterwards. This could be done with libelf I think.

The rtl-host is a wrapper to libelf which is included in the rtl-host 
code we are not dependent on host specifics or versions.

>> But I also wonder if it would not be better to focus on changing flow
>> of covoar - to avoid multiple runs (one for each symbol set as it
>> would be now), because it takes quite long. I think it should be done
>> in such way, that covoar reads symbol sets configuration file, runs
>> analysis and takes data for all desired symbols from all sets and
>> finally performs multiple reporting part, generating simple, generic
>> output for each symbols set.
>>
> Then covoar knows what purpose and scope of the reports are.  As it
> stands now, covoar knows NOTHING
> about RTEMS. Let's keep it that way.

Out of interest what is config file format for covoar ? I have added INI 
file support to the rtl-host repo and it seems stable and flexible.

>
> covoar gets slower as the set of symbols and tests grows. The standard
> run now already does at
> least two covoar runs. Once for "all" and one for "core". The build and
> test execution time dominates.

Where is bottleneck ? The RTL code uses an STL map for symbol look up.

> As we process smaller sets of symbols, covoar will be faster anyway.
> Besides, if it is slow enough,
> eventually we will profile and fix it. :)
>> Another job I am thinking about doing next is adding more bsps support
>> for coverage and getting things working on more bsps. This should be
>> quite simple.
>>
> This requires the simulator support. But you should be able to do arm
> and x86 with qemu.
>> There is still one problem waiting for decision :-) What with rtems
>> grub boot img for qemu? How should we integrate it into rtems-tools?
>>
> Chris?

Ah yes. I think we should download an image from a know spot but I have 
not looked into how to do this with the RSB.

Maybe building grub from source is possible but that can be something 
for another day.

Chris



More information about the devel mailing list