Coverage tools project direction [GSOC]

[Joel Sherrill]

I would.focus first on running coverture-qemu instead regular qemu. This
includes the rsb support but is just focused on parity with no coverage.

Then run coverture-qemu with coverage on by hand and see if it gets the
output either the old or new scripts expect. Do this with just one test.

Then fix and update patches  as needed so RTEMS-tester can enable a
coverage run.

While testing the old stuff, I had it in parts for testing purposes:
running with coverage and generating reports. I would run the report side
over and over on the same output.

So sorry about one step at a time. The old scripts were intended to be a
reference for you. That was a working procedure.

--joel

On Jun 4, 2017 5:37 AM, "Cillian O'Donnell" <cpodonnell8 at gmail.com> wrote:

> Hi Chris,
>
> > Which BSPs that support qemu are missing from the rtems-test tool?
>
>
> I suppose I had been thinking in terms of coverage and all I have is
> coverage.mc files for PC386, Leon 2 and Leon 3 but now that I'm
> thinking about it maybe all I need to do is to run the tests for qemu
> and couverture-qemu and compare the results and if they're similar I
> know couverture is working fine and I can move onto the RSB work. I'm
> looking for a bit of clarification myself.
>
> > first the ability to run a specific qemu for a BSP
>
>
> As I had understood it, we were swapping out qemu for couverture-qemu,
> there was no need to have both, although I could be wrong.
>
>
> > Where is the repo with the RTEMS Tester you are working on?
>
> All the changes are local at the moment, I have been holding off
> making the commits as I haven't been able to get coverage to
> successfully run yet. I'm hoping if I can get those bsps to run then
> I'll try and begin to get everything merged and get cracking on the
> rest of the bsps. The current state of things is I've managed to
> insulate the coverage work so it's at least no longer breaking what's
> already there and the coverage runs are all running into errors in
> qemu.cfg, probably the bsp options in the coverage.mc files, not sure
> what to use yet. All tests invalid, default to dry-run
>
> Thanks,
>
> Cillian.
>
> On 4 June 2017 at 03:56, Chris Johns <chrisj at rtems.org> wrote:
> > On 3/6/17 10:14 pm, Cillian O'Donnell wrote:
> >>
> >> I've just realised that I've been fixing problems with the RTEMS
> >> Tester work that has already been done to convert bash scripts to
> >> python, but I probably should of first been trying to get the old
> >> sim-scripts method working from rtems-testing repo because this will
> >> give me more bsps to test qemu with. So I'm now trying to fix the
> >> do_coverage runtime errors due to covoar and its related files being
> >> moved to RTEMS Tester.
> >
> > I would prefer we do not invest more time in the scripts in the
> rtems-testing
> > repo. I personally would like to move this repo to under Joel so it
> becomes a
> > personal repo for him and away from the top level because a new user
> could think
> > this is the way to test.
> >
> > Which BSPs that support qemu are missing from the rtems-test tool?
> >
> >> I just want to confirm if I'm heading in the right direction. First
> >> get the old sim-scripts method working. Test qemu against
> >> couverture-qemu for bsps common to both. Then do the RSB support for
> >> couverture-qemu. Then get the RTEMS Tester work running and convert
> >> the rest of the sim-scripts. Is that right, or should I continue with
> >> the RTEMS Tester work?
> >
> > I see 2 parts to the RTEMS Tester work, first the ability to run a
> specific qemu
> > for a BSP and the integration of the coverage support. Is this correct?
> >
> > Where is the repo with the RTEMS Tester you are working on? I saw a post
> the
> > other day with some extra output and was wanting to ask.
> >
> > 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/20170604/4174ecc9/attachment-0002.html>