<div dir="ltr">Hi, <div><br></div><div>Thanks for your replies :-) I didn't see librld.a because I had old version of repo and after updating it appears :-) </div><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div>There is still one problem waiting for decision :-) What with rtems grub boot img for qemu? How should we integrate it into rtems-tools? </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-13 22:31 GMT+02:00 Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 13/08/2014 7:03 pm, Krzysztof Mięsowicz wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br><div class="">
I think we have small misunderstanding here :-) I'm currently trying to<br>
move symbol generation to covoar - previously symbol list was generated<br>
in shell script do_coverage.sh and passed to covoar in configuration<br>
file or as a command line argument. What we want now is to allow covoar<br>
to generate symbols. Chris suggested that use of code in rtl-host repo<br>
to manage symbols (it seems to use elf libraries inside), but this was<br>
said to be out of the scope of this project - I am going to do this<br>
after end of SOCIS. But as the first approximation we decided to invoke<br>
nm from covoar, using functions from rld-process[cpp, h] and parse its<br>
output in covoar. I have it almost done, but currently I added building<br>
rtems-syms from rtl-host as library and use it in covoar. I don't know<br>
if this is right solution and how should it be done better :-)<br>
</div></blockquote>
<br>
Yes this was the discussion and it still make sense if you want to follow this path.<br>
<br>
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.<br>
<br>
Chris<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
<br>
2014-08-13 0:14 GMT+02:00 Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a><br></div>
<mailto:<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.<u></u>com</a>>>:<div class=""><br>
<br>
<br>
On 8/12/2014 6:58 AM, Krzysztof Mięsowicz wrote:<br>
> Hi,<br>
><br>
> I'm currently working on adding symbol generation to covoar. I'm<br>
going<br>
> to use rtl::process::execute function to run nm from covoar (as<br>
> suggested by Chris). I do not know exactly how should I use this in<br>
> covoar. Should I build rtl-host as a library and link it to<br>
covoar? Or<br>
> maybe there is another, better option?<br>
><br>
covoar is in C++ and you would be invoking Python instead of nm from C++<br>
and still producing something that the C++ has to read.<br>
<br>
Ian Taylor suggested using nm over the elf libraries because the output<br>
of nm was stable. But converting that code to use an elf reading library<br>
directly would likely be a better solution.<br>
<br>
If that's the use of nm you are talking about. :)<br>
<br>
Waiting to hear from Chris.<br>
<br>
> Thanks in advance for replies :)<br>
><br>
> Regards,<br>
> Krzysztof<br>
<br>
--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br></div>
Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a> <tel:%28256%29%20722-9985><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>