<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 12:13 PM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I just want to give an update to my understanding of this problem as<br>
I'm not sure I was clear enough in the IRC meeting. We ended up<br>
talking about nops but I think the problem is something else.<br>
<br>
So when there is a successful covoar run, it will generate a report<br>
but also finish with this message.<br>
<br>
*** Trace block is inconsistent with coverage map<br>
*** Trace block (0x4000c2cc - 0x4000c2ec) for 36 bytes<br>
*** Coverage map /home/cpod/coverage_test/<wbr>leon3/coverage/base_sp.exe.cov<br>
<br>
-----------------------------<br>
<br>
The coverage map is 24 bytes:<br>
<br>
(gdb) p/x *entry<br>
$2 = {pc = 0x4000c2cc, size = 0x24, op = 0x12}<br>
<br>
-----------------------------<br>
<br>
The disassembly block in question is:<br>
<br>
4000c2cc <_Objects_Get_information_id>:<br>
4000c2cc: 83 32 20 18 srl %o0, 0x18, %g1<br>
<br>
Objects_Information *_Objects_Get_information_id(<br>
Objects_Id id<br>
)<br>
{<br>
return _Objects_Get_information(<br>
4000c2d0: 93 32 20 1b srl %o0, 0x1b, %o1<br>
4000c2d4: 90 08 60 07 and %g1, 7, %o0<br>
4000c2d8: 82 13 c0 00 mov %o7, %g1<br>
4000c2dc: 40 00 00 02 call 4000c2e4 <_Objects_Get_information><br>
4000c2e0: 9e 10 40 00 mov %g1, %o7<br>
<br>
4000c2e4 <_Objects_Get_information>:<br>
<br>
Objects_Information *_Objects_Get_information(<br>
Objects_APIs the_api,<br>
uint16_t the_class<br>
)<br>
{<br>
4000c2e4: 9d e3 bf a0 save %sp, -96, %sp<br>
Objects_Information *info;<br>
int the_class_api_maximum;<br>
<br>
if ( !the_class )<br>
4000c2e8: 80 a6 60 00 cmp %i1, 0<br>
4000c2ec: 02 80 00 19 be 4000c350 <_Objects_Get_information+<wbr>0x6c><br>
4000c2f0: 01 00 00 00 nop<br>
<br>
------------------------------<wbr>------<br>
<br>
I have checked this out on base_sp.exe and ticker.exe where the same<br>
inconsistency appears in both. Couverture-QEMU decides the trace block<br>
encompasses that entire block<br>
<br>
Whereas from the covoar side the objdump is always processed line by<br>
line and a regex is checked to determine what kind of line it is.<br>
<br>
408 items = sscanf(<br>
409 inputBuffer,<br>
410 "%x <%[^>]>%c",<br>
411 &offset, symbol, &terminator1<br>
412 );<br>
<br>
If there is a match for all 3 items then this is a new function<br>
<br>
415 if ((items == 3) && (terminator1 == ':')) {<br>
416<br>
417 endAddress = executableInformation-><wbr>getLoadAddress() + offset - 1;<br>
<br>
<br>
So the objdump above is always processed as 2 seperate sections.<br>
<br>
One for:<br>
4000c2cc <_Objects_Get_information_id>:<br>
<br>
<br>
And one for:<br>
4000c2e4 <_Objects_Get_information>:<br>
<br>
The size from Objects_Get_information_id to Objects_Get_information is<br>
24 bytes which is the coverage map.<br>
The size of both functions combined is 36 bytes which is the<br>
Couverture trace block.<br></blockquote><div><br></div><div>OK. I think I finally understand enough to believe that covoar is at fault here.</div><div>It is complicated because of the multiple pieces in action but you have</div><div>given plenty of information. Let's see if I can explain how the different</div><div>sources of data are (incorrectly) being thought to not match up.</div><div><br></div><div>First, it is not about having a varying amount of padding at the end</div><div>of a method so the next method is on a cache-aligned boundary.</div><div><br></div><div>Qemu traces reflect that qemu executes "translation blocks" of code.</div><div>Each block is up to a point of potential change of execution flow. This</div><div>means they should always end with a call, return from subroutine,</div><div>branch, trap, etc. </div><div><br></div><div>Internally, covoar processes methods which have C statements and</div><div>assembly statements. Each method can have "ranges" of covered and</div><div>uncovered code. That's the basis for the reports at the end.</div><div><br></div><div>The trace reader for qemu is getting confused trying to interpret</div><div>the branch information. It is assuming that the branch is the</div><div>last instruction in the range in aCoverageMap. </div><div><br></div><div>For some unknown reason, the trace reader class appears to be</div><div>checking that the couverture trace record precisely matches the</div><div>size of the associated uncovered range. I don't think it always can.</div><div>It probably is always <= size of the code in aCoverageMap.</div><div><br></div><div>CoverageMapBase.cc has a "dump()" method to assist in debugging.</div><div><br></div><div>I think the math for associating the branch information is wrong.</div><div>It should compute the address of the branch instruction, verify</div><div>it is the start of an instruction, that it is a branch, and then set</div><div>was taken or was not taken.</div><div><br></div><div>Well..crap.. the output variables offset_t and offset_e from the calls being checked on the if:</div><div>are not even being used.</div><div><br></div><div><div> if ((aCoverageMap->determineOffset( a, &offset_a ) != true) ||</div><div> (aCoverageMap->determineOffset( entry->pc, &offset_e ) != true))</div><div> {</div><div> </div></div><div>Disable the if and check if things look better. </div><div><br></div><div>In other words, just assume that it is consistent. We have already looped</div><div>through the "aCoverageMap" and set was executed in the loop around</div><div>135. </div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Couverture could possibly be doing something more sophisticated to<br>
determine the end of the block or it could just be wrong. So the next<br>
thing I'm doing is figuring out exactly how Couverture is processing<br>
this.<br>
<br>
For both cases the trace op code is 0x12 which means 'Branch fully<br>
executed' and 'Branch not taken'. I'm trying to find one with op code<br>
0x11 which would mean the 'branch is taken' and possibly it might be<br>
processed differently in this case. The only place both these<br>
functions appear in the source is libtests/dl04 and dl05. I'm checking<br>
those out at the moment.<br>
<br>
Thanks,<br>
<br>
Cillian.<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div>