Coverage analysis update

[Joel Sherrill]

On Jul 6, 2017 8:52 PM, "Chris Johns" <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>> 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


> 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.


> 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.

Fwiw this thread needs to be split. There are multiple issues.


Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170706/043e6e34/attachment-0002.html>