diff options
author | Dean Deng <deandeng@google.com> | 2020-08-25 16:26:53 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2020-08-25 16:28:45 -0700 |
commit | cb573c8e0bf042ea111dc83c72f25d135623032f (patch) | |
tree | d0d1a4f4febe8ec3ca2c707a2a9a25d95cbc13b3 /website/assets | |
parent | 70a7a3ac704a47ec50525d06438ba4983da3af8b (diff) |
Expose basic coverage information to userspace through kcov interface.
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
Diffstat (limited to 'website/assets')
0 files changed, 0 insertions, 0 deletions