Using rtl-host in covor - some questions

[Joel Sherrill]

On 8/13/2014 10:13 PM, Chris Johns wrote:
> 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 ?
This is the user defining the set of symbols that they want to generate
coverage
reports on. For RTEMS, this is just looking at the set of libXXX.a in
the build
tree for each directory we analyze and extracting the symbols.

This is completely external to covoar. How a project generates its
symbol list
is project dependent. covoar only knows that it is to generate reports based
on that set of symbols, the .exe files, and the coverage files.

This is currently done using nm in the script that invokes covoar.
> We have a really good way to get at the symbols via C++ now with 0 
> parsing code or external tools.
OK.

>> 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.
Currently covoar uses system() to invoke nm (maybe with a sed) and then
process it
using regular file operations.

Personally, I don't see much difference between invoking nm and
rtl-host. Either
will require a system and then loading the symbol set from a file. On a
large set
of executables, this may be a large time consumer. It would be better to
directly
use libelf to read the symbols. It should simplify and speed things up.
>>> 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.
I think it is just name=value without sections. I honestly don't recall
but it is not fancy.
It could easily be switched to .ini.
>> 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.
See above. I think executing nm on each exe with whatever filter
commands and
then reading them. Using libelf directly will help a lot.

I don't recall any other hot spots but that there are places where you
have to
cycle over all exe's for all symbols of interest. That is obviously
O( num exes * num syms) but I don't think it is the big issue. I think
the first
issue is just like make vs waf. Avoid doing system() and parsing output
files
500 times (# tests) and just read the symbol table directly. That has to
be a
huge time saver
>> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985