MCDC Checker and RTEMS

This is likely not the best way to reach out but here goes. In the presentation "MC/DC for Space" linked to in the documentation, it is mentioned that you ran the tools on RTEMS SMP and found "few non-treelike BDDs". I have locally installed the Docker image (thanks) and think I have successfully run the checker on SMP and uniprocessor builds of RTEMS (git master) for sparc/leon3. I have run it over the score, rtems, posix, and libcsupport directories which is over 50% of "RTEMS proper." This leaves out BSPs, a lot of third-party code, the shell, and file systems. I am running the Docker on one source file at a time and every file gives the same output:

The following errors were found: No errors of type clang_parse_failed occurred No errors of type failed_to_create_bdd occurred No errors of type invalid_operator_nesting occurred No errors of type unexpected_node occurred No errors of type bdd_is_not_tree_like occurred No errors of type bdd_is_not_tree_like_and_has_too_many_nodes occurred

Is this OK and does this match what you found? I rather expected to find something needing a bit of rework in the core parts of RTEMS.

I did try to provide multiple files via the - argument which directs mcdc-checker to read a list of files from stdin. but that appears to not work at least with the Docker image:

$ find cpukit/score/src -name "*.c" | docker run --rm -it -v /home/joel/rtems-work/rtems:/rtems registry.gitlab.com/gtd-gmbh/mcdc-checker/mcdc-checker -I /rtems/b-leon3/sparc/leon3/cpukit/include -I /rtems/cpukit/include -I /rtems/cpukit/score/cpu//include -
the input device is not a TTY

If my use of the tools and the analysis of RTEMS not having anything of interest is correct, I would like to get some advice on running the tool more efficiently and getting less output when there is nothing to report. Invoking the Docker a file at a time is OK for a one-time analysis pass but I would like to add this to our CI and taking 30 minutes to run on this subset of RTEMS is not acceptable. I am sure that is a side-effect of how I am running this. I am using the attached script j-mcdc-rtems after building for sparc/leon3 so there is a cpuopts.h file generated.

I have long been encouraging people to write simple expressions to avoid the need for MC/DC analysis and expensive tools. This is why RTEMS has a tool to merge and map simulator trace output to coverage reports. If there is no MC/DC, great coverage is just a matter of all generated assembly and taking branch paths. I'm looking forward to being able to relax my guidance and incorporate mcdc-checker into our processes.

Thanks