proposal: package to parse coverage data

[avagin]

In gVisor, we implemented /sys/kernel/debug/kcov, which provides the user-space interface for kernel code coverage data. In this context, the "kernel" is the gVisor Sentry. For example, a guest process can execute a few system calls and then retrieve the coverage data for the Sentry code that have been executed by those syscalls. The main consumer of this feature is syzkaller (fuzzer).

Originally, /sys/kernel/debug/kcov was implemented based on the old coverage golang API: google/gvisor@cb573c8

We found that the new code coverage interface was introduced just recently when rules_go switched on it: bazel-contrib/rules_go#4397.

When I start working on adopting the new API, I found that there is no way to parser coverage data within an application. Coverage data can be saved in a file and then processed with the go tool cover tool. For gVisor, using a separate tool to process a coverage data isn't an option for both performance and security reasons. The Sentry is running in a completely isolated environments with strict seccomp rules.

As a temporary workaround, we are going to use internal packages: avagin/gvisor@1761620. From a long-term perspective, we want to have an upstream, public API to parse the coverage data.

[robpike]

It seems too rare a use case to necessitate a public package. You could just vendor the code you want into your repository.

[prattmic]

I think it would be great to have a package for working with coverage data. At GopherCon EU this year, I talked with someone that wanted to build custom coverage analysis tooling and found the lack of parsers painful. I've also heard requests for net/http/pprof to provide coverage data (though this technically doesn't need a new API).

It is also in line with our general desire/move towards empowering folks to build analysis tooling beyond what the Go toolchain provides. Profiling has supported this for a long time, since pprof is a standard format. #62627 proposes an API for parsing execution traces. IMO, expanding to coverage makes sense. These sorts of packages enable folks to do their own analysis in ways that are too niche to be built-in features in go tool pprof/trace/cover.

[prattmic]

cc @thanm @mknyszek

[prattmic]

To Rob's point, @avagin if I understand your patch correctly (I'm not super familiar with coverage internals), internal/coverage, internal/coverage/decodecounter, internal/coverage/decodemeta are purely for parsing and could theoretically be vendored.

But your use of internal/coverage/rtcov is to read the rtcov.Meta global variable, which provides the metadata for all of the instrumented packages, thus it can't be vendored.

Is there some reason you can't get the same metadata from runtime/coverage.WriteMeta? I see you are already using runtime/coverage.WriteCounters, so I assume the former has some limitation?

[avagin]

Is there some reason you can't get the same metadata from runtime/coverage.WriteMeta? I see you are already using runtime/coverage.WriteCounters, so I assume the former has some limitation?

Yeah, I probably can use runtime/coverage.WriteMeta. I don't think we will vendor these packages. For us, it's easier to use a patched version of go to access internal packages and avoid maintaining vendored packages.

[dzbarsky]

When we implemented coverage collection for child processes in rules_go, we also had to vendor a bit and hack into internal runtime packages. It would be great to have more of the coverage API surface public.

https://github.com/bazel-contrib/rules_go/blob/3ea65d884caedfae1036cdc8d0a758da900dc18b/go/tools/bzltestutil/bincov/coverage_visitor.go#L10