Coverage analysis update

[Chris Johns]

On 07/07/2017 12:58, Joel Sherrill wrote:
> On Jul 6, 2017 9:20 PM, "Chris Johns" <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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>>
>     >     > <mailto: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
>     <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?
> 

Oh nm is being used. What is objdump being used for?

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

I cannot tell, I do not know how this all works. I was wondering if the fewer
tools and files created the less room there is for error.

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

It may in the DWARF info which we do not have access to.

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

To load a symbol table you do this:

https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n466

After that you have a symbol table you can use to get at the symbols.

Chris