Using rtl-host in covor - some questions

[Krzysztof Mięsowicz]

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.

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.

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.

There is still one problem waiting for decision :-) What with rtems grub
boot img for qemu? How should we integrate it into rtems-tools?


2014-08-13 22:31 GMT+02:00 Chris Johns <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>>:
>>
>>
>>
>>     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>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140813/9ee03bc5/attachment-0002.html>