Coverage analysis update

[Chris Johns]

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.

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

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

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

This specific fragment I have created to address symbols?

Chris