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

[Chris Johns]

On 29/4/18 10:24 am, Joel Sherrill wrote:
> On Sat, Apr 28, 2018, 6:31 PM Chris Johns <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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.

I do not see this as something for GSoC. It is a requirement for covoar and not
this GSoC. These changes improve covoar's stability and portability but it does
not add value.

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

Yes this is why I am wanting to have this acknowledged as a task but not for
this GSoC.

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

It is great libdwarf has this support available but the rtemstoolkit wraps the
elftoolchain to manage access and so the support needs to integrate into there
and that is more complex.

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

Yes, this is something you and I need to take on. I think we have 2 steps, the
first is to review and do whatever simple cleanups we can and then we need to
support libdwarf which means adding a C++ framework.

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

I do not know. I know grep returns 2 dos2unix.

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

Don't you need libdwarf? And that means an upgrade of elftoolchain and then a
C=+ framework.

> 
> Objdump is harder to replace.
> 

It may be, I do not know. I also do not know where we place the various pieces
of functionality. The purpose of the rtemstoolkit is to provide reusable components.

> From a practical viewpoint, if Vijay is producing coverage reports and gcov
> files, the GSoC project could proceed without modification. 

I agree and this is what I think should happen.

> But we should all agree but that's what we want to do. Addr2line removal> may make sense first.

Not in GSoC, it is something we can do but that is outside the GSoC tasks.

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

Sure.

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

Please do not touch addr2line.

Chris