<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 8/13/2014 3:49 PM, Krzysztof
Mięsowicz wrote:<br>
</div>
<blockquote
cite="mid:CANNpagqBXDFaT_Uy6iEP6+2ztjDgf_s6GuF9O0e3wTFEPLWPhQ@mail.gmail.com"
type="cite">
<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>
</blockquote>
There are two uses of symbols in covoar.<br>
<br>
The first is external and it is generating the "symbols of interest"
for the run. That<br>
is currently a process that runs over the set of libraries of
interest and lists all the<br>
text symbols in those libraries. Doing that with the Python based
code should be a<br>
snap.<br>
<br>
The other part is in covoar itself. As it processes each exe and
builds the internal<br>
database of information, it needs the physical address of each
method of interest<br>
in that particular exe. That is done by an invocation of nm with
some magic processing<br>
afterwards. This could be done with libelf I think.<br>
<blockquote
cite="mid:CANNpagqBXDFaT_Uy6iEP6+2ztjDgf_s6GuF9O0e3wTFEPLWPhQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
Then covoar knows what purpose and scope of the reports are. As it
stands now, covoar knows NOTHING<br>
about RTEMS. Let's keep it that way. <br>
<br>
covoar gets slower as the set of symbols and tests grows. The
standard run now already does at<br>
least two covoar runs. Once for "all" and one for "core". The build
and test execution time dominates.<br>
As we process smaller sets of symbols, covoar will be faster
anyway. Besides, if it is slow enough,<br>
eventually we will profile and fix it. :)<br>
<blockquote
cite="mid:CANNpagqBXDFaT_Uy6iEP6+2ztjDgf_s6GuF9O0e3wTFEPLWPhQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
This requires the simulator support. But you should be able to do
arm and x86 with qemu.<br>
<blockquote
cite="mid:CANNpagqBXDFaT_Uy6iEP6+2ztjDgf_s6GuF9O0e3wTFEPLWPhQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
Chris?<br>
<blockquote
cite="mid:CANNpagqBXDFaT_Uy6iEP6+2ztjDgf_s6GuF9O0e3wTFEPLWPhQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-08-13 22:31 GMT+02:00 Chris Johns
<span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com"
target="_blank">joel.sherrill@oarcorp.com</a><br>
</div>
<mailto:<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.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>
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line
Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
</div>
Support Available <a moz-do-not-send="true"
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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</body>
</html>