<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jul 6, 2017 9:20 PM, "Chris Johns" <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 07/07/2017 12:10, Joel Sherrill wrote:<br>
><br>
><br>
> On Jul 6, 2017 8:52 PM, "Chris Johns" <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a><br>
</div><div class="quoted-text">> <mailto:<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>> wrote:<br>
><br>
> On 07/07/2017 00:34, Joel Sherrill wrote:<br>
> > On Thu, Jul 6, 2017 at 5:53 AM, Cillian O'Donnell <<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a><br>
> <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a>><br>
</div><div class="quoted-text">> > <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a> <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a>><wbr>>> wrote:<br>
> > It will ignore records when it thinks things are inconsistent. This can occur<br>
> > when a method appears in two different executables and has different<br>
> > sizes. The cause of this is usually padding at the end of the method so<br>
> > the subsequent method in memory starts on a nice cache-line alignment.<br>
> > The code tries to recognize the nops/padding at the end and ignore them.<br>
><br>
> The code in the linked executable can be different to the object file. The<br>
> linker does different things on different architectures and different link<br>
> orders.<br>
><br>
><br>
> We do not look at the .o files. The objdump output on exe files is used<br>
<br>
</div>I would like to see this changed to use:<br>
<br>
<a href="https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-symbols.h#n224" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-<wbr>tools/tree/rtemstoolkit/rld-<wbr>symbols.h#n224</a><br>
<br>
and to remove any objdump access. The toolkit will be much faster at loading a<br>
symbol table.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">That could replace the use of NM. Could it also replace objdump?</div><div dir="auto"><br></div><div dir="auto">It looks like now that he has problems with the Couverture trace and running in parallel which is independent.</div><div dir="auto"><br></div><div dir="auto">As a test, can you run all tests with coverage disabled? </div><div dir="auto"><br></div><div dir="auto">It would be helpful if running the tests and running covoar could be separate. Easier to debug.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> > When the padding inserted by ld changes or the objdump output being><br>
> parsed changes, covoar needs to be adjusted.<br>
><br>
> This means fragile.<br>
><br>
><br>
> Yes a bit. It has to be taught by architecture what padding LD puts in. But<br>
> this doesn't change often or for no reason.<br>
><br>
> Ian Taylor assured me years ago that the objdump output format was 5he most<br>
> stable way to do this.<br>
<br>
</div>We have direct access to the EFL file and symbols. I see that as a better solution.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">When things work. I think there are two issues ahead of any issues because of this. It has been on my wishlist but we need (1) to be to run all tests successfully and (2) to be sure the Couverture trace is read correctly.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> > The ignored record message I saw is in the code that reads Couverture<br>
> > trace records. The info in the record appears to be inconsistent with the<br>
> > code to which it has been matched.<br>
><br>
> Sorry, I do not understand why this difference is happening? I understand it is<br>
> object files vs executable, what I do not understand is why the object files are<br>
> being referenced, why not just use the executable?<br>
><br>
><br>
> No .o is used. We haven't parsed couverture trace format in years. It could have<br>
> changed. I **think** the message indicates that the qemu translation block is<br>
> reported as longer than from the current instruction to the end of the method.<br>
><br>
> The answer is to know the address range of the flagged trace block and what it<br>
> corresponds to in the exe.<br>
<br>
</div>I wonder if ELF holds the size of the area or can the symbol table sorted by<br>
address produce the needed ranges?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I do not know. I think it has the range but it would be straightforward I think to replace the use of NM.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
> Fwiw this thread needs to be split. There are multiple issues.<br>
<br>
</div>This specific fragment I have created to address symbols?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">If the issue is NM versus elf info, then it would help. Is there an RTEMS NM based on the library?</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Chris<br>
</font></blockquote></div><br></div></div></div>