<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 10:27 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 7 July 2017 at 03:58, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Jul 6, 2017 9:20 PM, "Chris Johns" <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br>
><br>
> 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>
>> <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<br>
>> <<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a><br>
>>     <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a>><br>
>>     > <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a> <mailto:<a href="mailto:cpodonnell8@gmail.com">cpodonnell8@gmail.com</a>><wbr>>><br>
>> wrote:<br>
>>     > It will ignore records when it thinks things are inconsistent. This<br>
>> 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<br>
>> so<br>
>>     > the subsequent method in memory starts on a nice cache-line<br>
>> alignment.<br>
>>     > The code tries to recognize the nops/padding at the end and ignore<br>
>> them.<br>
>><br>
>>     The code in the linked executable can be different to the object file.<br>
>> The<br>
>>     linker does different things on different architectures and different<br>
>> link<br>
>>     orders.<br>
>><br>
>><br>
>> We do not look at the .o files. The objdump output on exe files is used<br>
><br>
> 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<br>
> a<br>
> symbol table.<br>
><br>
><br>
> That could replace the use of NM. Could it also replace objdump?<br>
><br>
> It looks like now that he has problems with the Couverture trace and running<br>
> in parallel which is independent.<br>
<br>
</div></div>I ran rtems-test single threaded --jobs=1 and it locked up on the<br>
first executable base_sp.exe of the covoar run.<br>
<br>
  information->inactive_per_<wbr>block[ block ] = information->allocation_size;<br>
 4000c154:   c4 16 20 14     lduh  [ %i0 + 0x14 ], %g2<br>
 4000c158:   c6 06 20 30     ld  [ %i0 + 0x30 ], %g3<br>
<br>
Just stops here with no error message. So maybe the IO Error is about<br>
parallel tasks, I'd have to run it a few more times to be sure.<br></blockquote><div><br></div><div>This looks like qemu isn't completing the execution of the RTEMS application. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also I did compare qemu-traces.h with couverture's and there was a few<br>
changes to be made. It matches exactly now and I rebuilt covoar. It<br>
still lock's up as above though.<br>
<br>
Also I tried to build qemu-dump-traces like you mentioned Joel waf<br>
builds and doesn't complain about anything but there's no executable<br>
in the build directory, should there be? How does qemy-dump-traces<br>
work? The waf build looks like this:<br>
<br>
127     bld.program(target = 'qemu-dump-trace',<br>
128                 source = ['qemu-dump-trace.c'],<br>
129                 use = 'ccovoar',<br>
130                 cflags = ['-O2', '-g'],<br>
131                 includes = ['.'])<br>
<span class=""><br></span></blockquote><div><br></div><div>When you get a qemu-dump-trace executable, it is invoked like</div><div><br></div><div>..../qemu-dump-trace tracefile1... tracefileN</div><div><br></div><div>This is good to see if the information looks reasonable given the program you</div><div>are looking at the trace of. It is a very simple program and does **NOT**</div><div>contain any source code from covoar so it doesn't prove that covoar is</div><div>reading the trace correctly -- just that the basic look of the trace file is OK</div><div>given the hand inspection.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> As a test, can you run all tests with coverage disabled?<br>
<br>
</span>Yes the full testsuite runs fine with coverage disabled, it's only the<br>
post testsuite covoar runs that ever run into trouble<br></blockquote><div><br></div><div>If you comment out the execution of covoar in rtems-tester does it still hang.</div><div>Everything you post shows a SPARC trace which isn't from covoar execution.</div><div>Just print "would run covoar here and show the command line" :)</div><div><br></div><div>We need to be sure that an rtems-tester run completes with couverture</div><div>with both coverage tracing on and off. Without it invoking covoar. </div><div><br></div><div>Then you can run covoar by hand after using the output.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><br>
> It would be helpful if running the tests and running covoar could be<br>
> separate. Easier to debug.<br>
<br>
</span>This would be handy to not have to wait for the full testsuite to run<br>
every time to check if something has worked or not. I'm not sure how<br>
to separate the covoar part though.<br></blockquote><div><br></div><div>Save the configuration file from a single covoar run and print the</div><div>command line. You can save a build tree, trace files, etc. and just</div><div>run covoar by hand repeatedly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
><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.<br>
>> 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<br>
>> most<br>
>> stable way to do this.<br>
><br>
> We have direct access to the EFL file and symbols. I see that as a better<br>
> solution.<br>
><br>
><br>
> When things work. I think there are two issues ahead of any issues because<br>
> of this. It has been on my wishlist but we need (1) to be to run all tests<br>
> successfully and (2) to be sure the Couverture trace is read correctly.<br>
><br>
><br>
>>     > The ignored record message I saw is in the code that reads<br>
>> Couverture<br>
>>     > trace records. The info in the record appears to be inconsistent<br>
>> with the<br>
>>     > code to which it has been matched.<br>
>><br>
>>     Sorry, I do not understand why this difference is happening? I<br>
>> understand it is<br>
>>     object files vs executable, what I do not understand is why the object<br>
>> 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<br>
>> could have<br>
>> changed. I **think** the message indicates that the qemu translation block<br>
>> is<br>
>> reported as longer than from the current instruction to the end of the<br>
>> method.<br>
>><br>
>> The answer is to know the address range of the flagged trace block and<br>
>> what it<br>
>> corresponds to in the exe.<br>
><br>
> I wonder if ELF holds the size of the area or can the symbol table sorted by<br>
> address produce the needed ranges?<br>
><br>
><br>
> I do not know. I think it has the range but it would be straightforward I<br>
> think to replace the use of NM.<br>
><br>
><br>
>> Fwiw this thread needs to be split. There are multiple issues.<br>
><br>
> This specific fragment I have created to address symbols?<br>
><br>
><br>
> If the issue is NM versus elf info, then it would help. Is there an RTEMS NM<br>
> based on the library?<br>
><br>
><br>
> Chris<br>
><br>
><br>
</div></div></blockquote></div><br></div></div>