Using rtl-host in covor - some questions
Joel Sherrill
joel.sherrill at oarcorp.com
Wed Aug 13 21:34:23 UTC 2014
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.
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.
> 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.
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.
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?
>
> 2014-08-13 22:31 GMT+02:00 Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>>:
>
> On 13/08/2014 7:03 pm, Krzysztof Mięsowicz wrote:
>
> Hi,
>
> I think we have small misunderstanding here :-) I'm currently
> trying to
> move symbol generation to covoar - previously symbol list was
> generated
> in shell script do_coverage.sh and passed to covoar in
> configuration
> file or as a command line argument. What we want now is to
> allow covoar
> to generate symbols. Chris suggested that use of code in
> rtl-host repo
> to manage symbols (it seems to use elf libraries inside), but
> this was
> said to be out of the scope of this project - I am going to do
> this
> after end of SOCIS. But as the first approximation we decided
> to invoke
> nm from covoar, using functions from rld-process[cpp, h] and
> parse its
> output in covoar. I have it almost done, but currently I added
> building
> rtems-syms from rtl-host as library and use it in covoar. I
> don't know
> if this is right solution and how should it be done better :-)
>
>
> Yes this was the discussion and it still make sense if you want to
> follow this path.
>
> On the other hand ... :) .... once you link to librld.a you can
> with a small amount of code open an ELF file and read the symbols
> into a symbol table and get at the data that way. This is how the
> rtems-ld works when linking against an RTEMS kernel base image.
>
> Chris
>
>
>
> 2014-08-13 0:14 GMT+02:00 Joel Sherrill
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>
> <mailto:joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>>>:
>
>
>
> On 8/12/2014 6:58 AM, Krzysztof Mięsowicz wrote:
> > Hi,
> >
> > I'm currently working on adding symbol generation to
> covoar. I'm
> going
> > to use rtl::process::execute function to run nm from
> covoar (as
> > suggested by Chris). I do not know exactly how should I
> use this in
> > covoar. Should I build rtl-host as a library and link it to
> covoar? Or
> > maybe there is another, better option?
> >
> covoar is in C++ and you would be invoking Python instead
> of nm from C++
> and still producing something that the C++ has to read.
>
> Ian Taylor suggested using nm over the elf libraries
> because the output
> of nm was stable. But converting that code to use an elf
> reading library
> directly would likely be a better solution.
>
> If that's the use of nm you are talking about. :)
>
> Waiting to hear from Chris.
>
> > Thanks in advance for replies :)
> >
> > Regards,
> > Krzysztof
>
> --
> 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
> <tel:%28256%29%20722-9985> <tel:%28256%29%20722-9985>
>
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140813/6a07be2f/attachment.html>
More information about the devel
mailing list