[PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Joel Sherrill]

On Sat, Apr 28, 2018, 6:31 PM Chris Johns <chrisj at rtems.org> wrote:

> On 29/4/18 8:27 am, Cillian O'Donnell wrote:
> >
> >
> > On Sat, 28 Apr 2018, 20:39 Vijay Kumar Banerjee, <
> vijaykumar9597 at gmail.com
> > <mailto:vijaykumar9597 at gmail.com>> wrote:
> >
> >
> >     This is the log file that I'm getting after running the test
> >
> >     I'm getting  a lot of 'invalid' results , am I missing something ?
> >
> >
> > What we had in coverage.py and test.py will need to be updated with
> Chris'
> > change to covoar. It's probably best not to run it with rtems-test until
> we've
> > revised that.
>
> Yes this is the plan.
>
> > We'll just be testing covoar by itself for the moment. The focus
> > will probably be on removing covoars dependency on external tools next.
>
> Removing all the external exec is a complex problem to solve, for example
> to
> remove addr2lin we need to add libdwarf to the rtemstoolkit and that is
> not in
> the planned work for this GSoC.
>

Yes. But if we view this as a requirement to start the GSoC project, we can
adjust the project.

Programmatically this may be simple assuming an addr2line query is easy
with libdwarf. We could then replace that exec with a new helper class
call. But adding libfwarf to rtems-tools may be harder.

I was looking for a libdwarf example program that did something with file
and line information. But from my phone, it is hard to look at that kind of
code.


> Once these patches have been pushed to master I will look for solutions to
> get
> what we have working on all platforms, for example removing the dos2unix
> command.
>
> > Chris will we pass in the score ini to -S option now and then the other
> options
> > are picked up from there? (Excluding -p and -E).
>
> I am not sure yet. Once you are happy with the changes I have made I was
> going
> to take the rtems-tester patches and update them.
>
> For example I have side stepped the issue of detected a coverage version
> of qemu
> or having a coverage enable flag by creating leon3-qemu-cov as a BSP and
> if that
> is used with RTEMS tester it expects a coverage qemu to be available.
>

This is not a bad solution.

>
> >     after this patch along with with the c++ cleanup patch, we have to
> start
> >     working on parsing the coverage right?
>
> I am not sure, Joel? :)
>

Chris has identified removing the use of exec() as a goal. Plus some other
clean up. I assume the clean up list from him without exec is something I
can nibble on and has no impact on the GSoC project.

Are there shell/exec calls left other than addr2line and objdump?

Addr2line usage looks easier to eliminate. Get an example program working
that does the addr2line query and then turn that into a helper class.

Objdump is harder to replace.

>From a practical viewpoint, if Vijay is producing coverage reports and gcov
files, the GSoC project could proceed without modification. But we should
all agree but that's what we want to do. Addr2line removal may make sense
first.

For sure any cleanup or other issues in covoar that we are deferring for
even the briefest time need a ticket.

Chris.. Good reasons to fix addr2line usage or just push forward. I am
leaning to asking Vijay to address addr2line first but we have to decide
about who handles libdwarf integration.

>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180429/e0ecd81e/attachment-0002.html>