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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
