Coverage analysis update

[Cillian O'Donnell]

On 7 July 2017 at 03:58, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Jul 6, 2017 9:20 PM, "Chris Johns" <chrisj at rtems.org> wrote:
>
> On 07/07/2017 12:10, Joel Sherrill wrote:
>>
>>
>> On Jul 6, 2017 8:52 PM, "Chris Johns" <chrisj at rtems.org
>> <mailto:chrisj at rtems.org>> wrote:
>>
>>     On 07/07/2017 00:34, Joel Sherrill wrote:
>>     > On Thu, Jul 6, 2017 at 5:53 AM, Cillian O'Donnell
>> <cpodonnell8 at gmail.com
>>     <mailto:cpodonnell8 at gmail.com>
>>     > <mailto:cpodonnell8 at gmail.com <mailto:cpodonnell8 at gmail.com>>>
>> wrote:
>>     > It will ignore records when it thinks things are inconsistent. This
>> can occur
>>     > when a method appears in two different executables and has different
>>     > sizes. The cause of this is usually padding at the end of the method
>> so
>>     > the subsequent method in memory starts on a nice cache-line
>> alignment.
>>     > The code tries to recognize the nops/padding at the end and ignore
>> them.
>>
>>     The code in the linked executable can be different to the object file.
>> The
>>     linker does different things on different architectures and different
>> link
>>     orders.
>>
>>
>> We do not look at the .o files. The objdump output on exe files is used
>
> I would like to see this changed to use:
>
> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-symbols.h#n224
>
> and to remove any objdump access. The toolkit will be much faster at loading
> a
> symbol table.
>
>
> That could replace the use of NM. Could it also replace objdump?
>
> It looks like now that he has problems with the Couverture trace and running
> in parallel which is independent.

I ran rtems-test single threaded --jobs=1 and it locked up on the
first executable base_sp.exe of the covoar run.

  information->inactive_per_block[ block ] = information->allocation_size;
 4000c154:   c4 16 20 14     lduh  [ %i0 + 0x14 ], %g2
 4000c158:   c6 06 20 30     ld  [ %i0 + 0x30 ], %g3

Just stops here with no error message. So maybe the IO Error is about
parallel tasks, I'd have to run it a few more times to be sure.

Also I did compare qemu-traces.h with couverture's and there was a few
changes to be made. It matches exactly now and I rebuilt covoar. It
still lock's up as above though.

Also I tried to build qemu-dump-traces like you mentioned Joel waf
builds and doesn't complain about anything but there's no executable
in the build directory, should there be? How does qemy-dump-traces
work? The waf build looks like this:

127     bld.program(target = 'qemu-dump-trace',
128                 source = ['qemu-dump-trace.c'],
129                 use = 'ccovoar',
130                 cflags = ['-O2', '-g'],
131                 includes = ['.'])

>
> As a test, can you run all tests with coverage disabled?

Yes the full testsuite runs fine with coverage disabled, it's only the
post testsuite covoar runs that ever run into trouble
>
> It would be helpful if running the tests and running covoar could be
> separate. Easier to debug.

This would be handy to not have to wait for the full testsuite to run
every time to check if something has worked or not. I'm not sure how
to separate the covoar part though.
>
>
>>     > When the padding inserted by ld changes or the objdump output being>
>>     parsed changes, covoar needs to be adjusted.
>>
>>     This means fragile.
>>
>>
>> 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.
>>
>> Ian Taylor assured me years ago that the objdump output format was 5he
>> most
>> stable way to do this.
>
> We have direct access to the EFL file and symbols. I see that as a better
> solution.
>
>
> When things work. I think there are two issues ahead of any issues because
> of this. It has been on my wishlist but we need (1) to be to run all tests
> successfully and (2) to be sure the Couverture trace is read correctly.
>
>
>>     > The ignored record message I saw is in the code that reads
>> Couverture
>>     > trace records. The info in the record appears to be inconsistent
>> with the
>>     > code to which it has been matched.
>>
>>     Sorry, I do not understand why this difference is happening? I
>> understand it is
>>     object files vs executable, what I do not understand is why the object
>> files are
>>     being referenced, why not just use the executable?
>>
>>
>> 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.
>>
>> The answer is to know the address range of the flagged trace block and
>> what it
>> corresponds to in the exe.
>
> I wonder if ELF holds the size of the area or can the symbol table sorted by
> address produce the needed ranges?
>
>
> I do not know. I think it has the range but it would be straightforward I
> think to replace the use of NM.
>
>
>> Fwiw this thread needs to be split. There are multiple issues.
>
> This specific fragment I have created to address symbols?
>
>
> If the issue is NM versus elf info, then it would help. Is there an RTEMS NM
> based on the library?
>
>
> Chris
>
>