Coverage analysis update

Fri Jul 7 16:19:11 UTC 2017

On Fri, Jul 7, 2017 at 10:27 AM, Cillian O'Donnell <cpodonnell8 at gmail.com>
wrote:

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

This looks like qemu isn't completing the execution of the RTEMS
application.

>
> 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 = ['.'])
>
>
When you get a qemu-dump-trace executable, it is invoked like

..../qemu-dump-trace tracefile1... tracefileN

This is good to see if the information looks reasonable given the program
you
are looking at the trace of. It is a very simple program and does **NOT**
contain any source code from covoar so it doesn't prove that covoar is
reading the trace correctly -- just that the basic look of the trace file
is OK
given the hand inspection.

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

If you comment out the execution of covoar in rtems-tester does it still
hang.
Everything you post shows a SPARC trace which isn't from covoar execution.
Just print "would run covoar here and show the command line" :)

We need to be sure that an rtems-tester run completes with couverture
with both coverage tracing on and off. Without it invoking covoar.

Then you can run covoar by hand after using the output.

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

Save the configuration file from a single covoar run and print the
command line. You can save a build tree, trace files, etc. and just
run covoar by hand repeatedly.

> >
> >
> >>     > 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/20170707/e28ed252/attachment-0002.html>