关于 Linux 内核中的 gcov 输出？

Question

我在 Linux 内核树中运行 gcov，我得到了正确的报告，但是打印在每个文件头的一些摘要不正确，如下所示：-

    -:    0:Graph:page_alloc.gcno
    -:    0:Data:page_alloc.gcda
    -:    0:Runs:0
    -:    0:Programs:0

在这里我们可以看到运行次数和程序运行次数变为零，这是不正确的。这个错误可能是什么原因？

Answer 1

从这里开始：

https://www.kernel.org/doc/Documentation/gcov.txt

您是否能够看到系统中的所有以下文件（在 /sys/kernel/debug 上使用 debugfs 安装）：

/sys/kernel/debug/gcov
/sys/kernel/debug/gcov/reset
/sys/kernel/debug/gcov/path/to/compile/dir/file.gcda
/sys/kernel/debug/gcov/path/to/compile/dir/file.gcno

“/path/to/compile/dir”取决于您的内核文件。

然后你应用 gcov 命令：

# cd /tmp/linux-out
# gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel spinlock.c

而且 bugzilla.kernel.org 似乎没有任何 gcov 错误，除了一个。

https://bugzilla.kernel.org/show_bug.cgi?id=57621

很可能是您的设置错误或命令行问题。

关于从 /sys/kernel/debug 读取的另一件事：这些是读取内核内部计数器的接口。如果您没有在用户空间级别执行任何操作，这将导致触发您对分析感兴趣的内核函数，那么输出将始终保持为零。因此，请继续在用户空间中执行尽可能多的活动（例如，如果您对文件系统 API 感兴趣，则使用“ls -alR /”从根目录开始执行递归读取，或者如果您对文件系统 API 感兴趣，则使用“ps -ef”或“netstat”如果您想分析网络 API，则对 procfs 或“wget/ping”命令感兴趣。）

对于您跟踪“page_alloc”的情况，建议发出此命令：

zip -r /tmp/my.zip /home/xxx

这有望触发使用动态内存读取 /home/xxx 中的文件，然后将其压缩。压缩算法通常要求您在开始压缩之前分配足以包含所有数据的内存。 （这与加密算法相反，它可能只需要一块固定的内存来完成所有的加密，因此不会出现很多“page_alloc”内核调用）。

就我而言，我只关注一个文件：kernel/sched/core.c:

gcov -o /sys/kernel/debug/gcov/home/tthtlc/linux_latest/kernel/sched core.c

然后用vi查看core.c.gcov文件：

  2396808:   98:void update_rq_clock(struct rq *rq)
        -:   99:{
        -:  100:    s64 delta;
        -:  101:
        -:  102:    lockdep_assert_held(&rq->lock);
        -:  103:
  2396808:  104:    if (rq->clock_skip_update & RQCF_ACT_SKIP)
        -:  105:        return;
        -:  106:
  1676266:  107:    delta = sched_clock_cpu(cpu_of(rq)) - rq->clock;
  1677622:  108:    if (delta < 0)
        -:  109:        return;
  1677556:  110:    rq->clock += delta;
        -:  111:    update_rq_clock_task(rq, delta);
        -:  112:}

所以你可以看到它已经执行了很多次了。

并为 _alloc 做一个 grep：

core.c.gcov:        -: 5325:static struct ctl_table *sd_alloc_ctl_entry(int n)
core.c.gcov:       16: 5376:sd_alloc_ctl_domain_table(struct sched_domain *sd)
core.c.gcov:        -: 5378:    struct ctl_table *table = sd_alloc_ctl_entry(14);
core.c.gcov:        8: 5416:static struct ctl_table *sd_alloc_ctl_cpu_table(int cpu)
core.c.gcov:        8: 5425:    entry = table = sd_alloc_ctl_entry(domain_num + 1);
core.c.gcov:       16: 5434:        entry->child = sd_alloc_ctl_domain_table(sd);
core.c.gcov:        1: 5445:    struct ctl_table *entry = sd_alloc_ctl_entry(cpu_num + 1);
core.c.gcov:        8: 5458:        entry->child = sd_alloc_ctl_cpu_table(i);
core.c.gcov:        -: 6086:enum s_alloc {
core.c.gcov:       28: 6217:        atomic_set(&(*sg)->sgc->ref, 1); /* for claim_allocations */
core.c.gcov:        -: 6346:static int __sdt_alloc(const struct cpumask *cpu_map);
core.c.gcov:        1: 6348:static void __free_domain_allocs(struct s_data *d, enum s_alloc what,
core.c.gcov:        1: 6364:static enum s_alloc __visit_domain_allocation_hell(struct s_data *d,
core.c.gcov:        1: 6369:    if (__sdt_alloc(cpu_map))
core.c.gcov:        -: 6382: * sched_group structure so that the subsequent __free_domain_allocs()
core.c.gcov:       16: 6385:static void claim_allocations(int cpu, struct sched_domain *sd)
core.c.gcov:        1: 6845:static int __sdt_alloc(const struct cpumask *cpu_map)
core.c.gcov:        -: 6971:    enum s_alloc alloc_state;
core.c.gcov:        1: 6976:    alloc_state = __visit_domain_allocation_hell(&d, cpu_map);
core.c.gcov:       16: 7016:            claim_allocations(i, sd);
core.c.gcov:        1: 7031:    __free_domain_allocs(&d, alloc_state, cpu_map);
core.c.gcov:        4: 8198:cpu_cgroup_css_alloc(struct cgroup_subsys_state *parent_css)
core.c.gcov:        -: 8595:    .css_alloc  = cpu_cgroup_css_alloc,

如果您能详细说明您的详细设置并使用 gcov 访问系统，也许会有所帮助。