add gcov support and export results as files in debugfs
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sys/gnu/gcov/gcc_4_7.c | ||
|---|---|---|
| 1 ↗ | (On Diff #54101) | Color me ignorant... is this code obtained from a GPL project by chance? |
| sys/gnu/gcov/gcov_subr.c | ||
| 60 ↗ | (On Diff #54101) | Is this defined in libkern? |
| 119 ↗ | (On Diff #54101) | I disagree with this assertion. If someone is intentionally calling __gcov_flush, it means that they anticipate the coverage information to have been flushed out to disk. In particular, if the kernel panics and this is treated as a no-op, the coverage data could be corrupted, rendering the data useless. |
| sys/gnu/gcov/gcc_4_7.c | ||
|---|---|---|
| 1 ↗ | (On Diff #54101) | It's tightly coupled with gcc internals. There's no way around it. And frankly it's not a useful concern as one would never ship a profiling kernel. |
| sys/gnu/gcov/gcov_subr.c | ||
| 119 ↗ | (On Diff #54101) | The data isn't being written synchronously. It's being exported by way of pseudofs for the user to collect. If you care about not losing data, collect after every test. The coverage of a kernel test that panics would be lost when using anything other than battery backed RAM. This is currently a direct port of what Linux does. |
| sys/gnu/gcov/gcov_subr.c | ||
|---|---|---|
| 60 ↗ | (On Diff #54101) | No. It's copied from libc. Otherwise I wouldn't add a private copy. |