<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 24, 2019 at 8:46 AM Jiri Gaisler <<a href="mailto:jiri@gaisler.se">jiri@gaisler.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="gmail-m_2701056588364156586moz-cite-prefix">On 1/24/19 2:19 PM, Joel Sherrill
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">
        <div><br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr">On Thu, Jan 24, 2019, 6:38 AM Jiri Gaisler
              <<a href="mailto:jiri@gaisler.se" target="_blank">jiri@gaisler.se</a> wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Small
              patch to fix covoar to work with TSIM coverage files. It
              should be noted that covoar erroneously marks some code as
              uncovered while it is marked as covered in the coverage
              file. This seems to be due to incorrect parsing of the
              symbol table in the exec file. I will file a ticket for
              this on trac ..<br>
            </blockquote>
          </div>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Is this the entry and exit code of a method or
          something else? The switch to dwarf info seems to have caused
          that and not marking assembly from inlined methods. <br>
        </div>
      </div>
    </blockquote>
    <p>I notice two problems: the first instruction in a range is
      sometimes marked as uncovered:<br>
    </p>
    <p>4000807c <_Freechain_Get>:<br>
        Freechain_Control   *freechain,<br>
        Freechain_Allocator  allocator,<br>
        size_t               number_nodes_to_extend,<br>
        size_t               node_size<br>
      )<br>
      {<br>
      4000807c:       9d e3 bf a0     save  %sp, -96, %sp<br>
                                 <== NOT EXECUTED<br>
      40008080:       ba 10 00 18     mov  %i0, %i5<br>
      <br>
        return _Chain_Immutable_head( the_chain )->next;<br>
      <br>
      40008084:       f0 06 00 00     ld  [ %i0 ], %i0<br>
    </p>
    <p>even though it is marked as executed in the coverage file. The
      second problems is that the size of ranges is sometimes off by one
      byte, e.g. 21 bytes instead of 20. This can only be seen when
      debugging covoar in gdb.</p></div></blockquote><div><br></div><div>I recall that the CoverageReaderTSIM code did an offset of +1 to +4 from the address. Perhaps it just needs to be 0-3. :)</div><div><br></div><div>The off by one on the ranges is something else.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <p>I will prepare a patch for sis to add the coverage, and then
      covoar can be debugged using our standard tools. Maybe it could be
      a task for GSoC ...? An additional task could also be to add
      RISC-V support to covoar, which is currently missing...<br></p></div></blockquote><div><br></div><div>Yes on GSoC. Use the keywords "SoC, testing" and it will show up in the list here:</div><div><br></div><div><a href="https://devel.rtems.org/wiki/Developer/OpenProjects">https://devel.rtems.org/wiki/Developer/OpenProjects</a><br></div><div><br></div><div>Clearly one bug isn't a GSoC project but if we file tickets for all the issues, then that's a GSoC project.</div><div><br></div><div>RISC-V support would be awesome! I am thrilled you have added support for it. :)</div><div><br></div><div>--joel</div><div> </div></div></div></div></div>