<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 13 May 2018, 16:09 Cillian O'Donnell, <<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>It does seem to be having some knock on effect. Covoar made it past these checks before.<br><br>-----------------<br>Total: 13<br>Average test time: 0:00:03.178923<br>Testing time : 0:00:41.326000<br>Running covoar for score<br>covoar results directory:<br>/home/cpod/development/rtems/leon3/coverage/score<br>ERROR: executable build prefix does not match: sparc-rtems5<br>***Cleaning tempfiles***<br>error: covoar failure exit code: 1<br><br></div>Not sure how thats related.<br><br></div>Its checking<br><br> if (buildPrefix.empty()) { <br> 76 buildPrefix = *pri; <br> 77 } else { <br> 78 if (buildPrefix != *pri) { <br> 79 std::cout << "buildBSP: " + buildBSP << "\n*pri: " + *pri << std::en<br> dl;<br> 80 fail = "executable build prefix does not match: " + buildPrefix; <br> 81 break; <br> 82 } <br> 83 } <br><br></div>I added those checks, Its stepping back through the path and checking if each directory makes sense. It seems to be out of line now<br><br>ERROR: executable build prefix does not match: sparc-rtems5<br>buildBSP: leon3<br>*pri: sparc-rtems5<br>***Cleaning tempfiles***<br></div></div></blockquote></div></div><div dir="auto">initially there were two problems </div><div dir="auto">+exe.cov and .cov mismatch</div><div dir="auto">+access library from outside the leon3 directory. </div><div dir="auto"><br></div><div dir="auto">The patch solves the first one, that's one step .</div><div dir="auto">The next step can be solved by adding the path to the build-target , i.e. sparc-rtems5 , from HOME directory, you can manually add it and see it running for now. That tells us that inclusion of the path in more standard way will solve it .</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>Maybe its splitting the path on '.' and '/' Haven't checked it yet. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 May 2018 at 07:05, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_8264131931155976820h5">On 13 May 2018 at 10:50, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 13/5/18 4:44 pm, Vijay Kumar Banerjee wrote:<br>
> On Sun, 13 May 2018, 10:09 Chris Johns, <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a><br>
</span><div><div class="m_8264131931155976820m_7450967645207311306h5">> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>>> wrote:<br>
> ><br>
> > Coverage::CoverageFormats_t coverageFormat =<br>
> > Coverage::COVERAGE_FORMAT_QEMU;<br>
> > Coverage::CoverageReaderBase* coverageReader = NULL;<br>
> > char* executable = NULL;<br>
> > @@ -317,11 +317,12 @@ int main(<br>
> > std::cerr << "warning: Unable to read executable: " << argv[i] <<<br>
> > std::endl;<br>
> > } else {<br>
> > coverageFileName = argv[i];<br>
> > - coverageFileName.replace(<br>
> > + coverageFileName.append(coverageExtension);<br>
> > + /* coverageFileName.replace(<br>
> > coverageFileName.length() - executableExtension.size(),<br>
> > executableExtension.size(),<br>
> > coverageExtension<br>
> > - );<br>
> > + ); */<br>
> ><br>
> ><br>
> > <br>
> > If you are replacing this call, then just delete it -- don't comment it out.<br>
> ><br>
> <br>
> I suggest the replace be changed to move past the '.' in the file name.<br>
> <br>
> I suspect the code here is still fragile because the extensions need to be the<br>
> same size.<br>
> <br>
> can't this be done by adding '.' in the append as in the v2 of this patch to<br>
> keep the extension size same ?<br>
<br>
</div></div>It fixes something but what is broken that is being fixed?<br>
<span><br></span></blockquote></div></div><div>the trace files have .exe.cov extensions but the covoar was searching for .cov extension causing it to return error for not finding the trace file. Adding the .cov to the coverageFileName to make it .exe.cov seemed like a quick fix to this .</div><div><br></div><div>Do we need the .exe extension there ? </div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> are you suggesting to use replace instead ?<br>
<br>
</span>I think it would be better to fix the bug than work around it.<br>
<br>
The replace is saying replace from length of the extension back from the end of<br>
the string for the size of the extension with the extension. In other words it<br>
should back up from the end the extension length and replace it. Which length or<br>
size is wrong.<br>
<br>
No matter what the current code is fragile because it assumes a few things. The<br>
most robust approach would add code to the rtemstoolkit's rld::path namespace to<br>
return a path with the extension stripped. For example add<br>
'rld::path::strip_extension ()' and then use that to strip coverageFileName and<br>
then add the extension.<br>
<br>
I would also review the 'exe' extension usage to make sure it is OK. I have not<br>
done this.<br>
<br>
Are you interested in doing this?<br></blockquote><div> </div></span><div>I can look into this. Any instructions ? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="m_8264131931155976820m_7450967645207311306HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div>