Using rtl-host in covor - some questions

[Chris Johns]

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