<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jul 6, 2017 8:52 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 00:34, Joel Sherrill wrote:<br>
</div><div class="quoted-text">> On Thu, Jul 6, 2017 at 5:53 AM, Cillian O'Donnell <<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>><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>
</div>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 orders.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">We do not look at the .o files. The objdump output on exe files is used</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> parsed changes, covoar needs to be adjusted.<br>
<br>
</div>This means fragile.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Yes a bit.  It has to be taught by architecture what padding LD puts in. But this doesn't change often or for no reason.</div><div dir="auto"><br></div><div dir="auto">Ian Taylor assured me years ago that the objdump output format was 5he most stable way to do this.</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>
</div>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></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">No .o is used. We haven't parsed couverture trace format in years. It could have changed. I **think** the message indicates that the qemu translation block is reported as longer than from the current instruction to the end of the method. </div><div dir="auto"><br></div><div dir="auto">The answer is to know the address range of the flagged trace block and what it corresponds to in the exe.</div><div dir="auto"><br></div><div dir="auto">Fwiw this thread needs to be split. There are multiple issues. </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>