summaryrefslogtreecommitdiffhomepage
path: root/pkg/coverage
AgeCommit message (Collapse)Author
2021-01-22Merge release-20210112.0-72-g65594d30a (automated)gVisor bot
2021-01-22Avoid atomic operations in kcov processing.Dean Deng
Atomic operations here significantly slow down gVisor builds with kcov/coverage enabled. Also mark these functions go:norace to avoid complaints from the race detector. PiperOrigin-RevId: 353281865
2020-12-11Merge release-20201208.0-35-g80379894d (automated)gVisor bot
2020-12-11Add runsc symbolize command.Dean Deng
This command takes instruction pointers from stdin and converts them into their corresponding file names and line/column numbers in the runsc source code. The inputs are not interpreted as actual addresses, but as synthetic values that are exposed through /sys/kernel/debug/kcov. One can extract coverage information from kcov and translate those values into locations in the source code by running symbolize on the same runsc binary. This will allow us to generate syzkaller coverage reports. PiperOrigin-RevId: 347089624
2020-11-13Automated rollback of changelist 341640485Dean Deng
PiperOrigin-RevId: 342297902
2020-11-10Add logging to internal gvisor when checking for kcov.Dean Deng
May help with debugging https://syzkaller.appspot.com/bug?id=0d717bd7028dceeb4b38f09aab2841c398b41d81 PiperOrigin-RevId: 341640485
2020-09-27Merge release-20200921.0-53-g2a60f9229 (automated)gVisor bot
2020-09-27Clean up kcov.Dean Deng
Previously, we did not check the kcov mode when performing task work. As a result, disabling kcov did not do anything. Also avoid expensive atomic RMW when consuming coverage data. We don't need the swap if the value is already zero (which is most of the time), and it is ok if there are slight inconsistencies due to a race between coverage data generation (incrementing the value) and consumption (reading a nonzero value and writing zero). PiperOrigin-RevId: 334049207
2020-08-25Merge release-20200818.0-54-gcb573c8e0 (automated)gVisor bot
2020-08-25Expose basic coverage information to userspace through kcov interface.Dean Deng
In Linux, a kernel configuration is set that compiles the kernel with a custom function that is called at the beginning of every basic block, which updates the memory-mapped coverage information. The Go coverage tool does not allow us to inject arbitrary instructions into basic blocks, but it does provide data that we can convert to a kcov-like format and transfer them to userspace through a memory mapping. Note that this is not a strict implementation of kcov, which is especially tricky to do because we do not have the same coverage tools available in Go that that are available for the actual Linux kernel. In Linux, a kernel configuration is set that compiles the kernel with a custom function that is called at the beginning of every basic block to write program counters to the kcov memory mapping. In Go, however, coverage tools only give us a count of basic blocks as they are executed. Every time we return to userspace, we collect the coverage information and write out PCs for each block that was executed, providing userspace with the illusion that the kcov data is always up to date. For convenience, we also generate a unique synthetic PC for each block instead of using actual PCs. Finally, we do not provide thread-specific coverage data (each kcov instance only contains PCs executed by the thread owning it); instead, we will supply data for any file specified by -- instrumentation_filter. Also, fix issue in nogo that was causing pkg/coverage:coverage_nogo compilation to fail. PiperOrigin-RevId: 328426526