关于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 /内核/调试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 /”从根开始递归读取;如果您是用户，则使用“ps -ef”或“netstat” 。感兴趣的PROCFS，或者如果要分析网络API“的wget /平”命令）

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

拉链-R/tmp目录/my.zip/home/xxx

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

对于我来说，我只专注于一个文件：内核/排程/ 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的访问系统。