Coverage analysis update

[Joel Sherrill]

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.

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

It would be helpful if running the tests and running covoar could be
separate. Easier to debug.


>     > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170706/ff56703a/attachment-0002.html>