为什么 strace 会根据环境/内核忽略一些系统调用（随机）？答案

【问题标题】：Why does strace ignore some syscalls (randomly) depending on environment/kernel?为什么 strace 会根据环境/内核忽略一些系统调用（随机）？
【发布时间】：2021-07-26 18:58:05
【问题描述】：

如果我编译以下程序：

$ cat main.cpp && g++ main.cpp
#include <time.h>
int main() {
    struct timespec ts;
    return clock_gettime(CLOCK_MONOTONIC, &ts);
}

然后在“标准”Kubuntu 中的strace 下运行它，我明白了：

strace -tt --trace=clock_gettime ./a.out
17:58:40.395200 +++ exited with 0 +++

如您所见，没有clock_gettime（完整的strace 输出为here）。

另一方面，如果我在 qemu 下自定义构建的 linux 内核中运行相同的应用程序，我会得到以下输出：

strace -tt --trace=clock_gettime ./a.out
18:00:53.082115 clock_gettime(CLOCK_MONOTONIC, {tv_sec=101481, tv_nsec=107976517}) = 0
18:00:53.082331 +++ exited with 0 +++

哪个更值得期待 - 有 clock_gettime。

所以，我的问题是：

如果我在 Kubuntu 中运行 strace，为什么会忽略/忽略 clock_gettime？
为什么strace 的行为因环境/内核而异？

【问题讨论】：

只是一个想法：第一个示例中没有系统调用。手册页告诉 CLOCK_MONOTONIC_COARSE 将使用 vdso，但可能以后的 glibc 也可能能够优化您的函数以不调用内核（使用系统调用）。 GUI 可能会经常使用此类计时功能，因此任何优化都是显而易见的
是的，有道理。您能否将这个“CLOCK_MONOTONIC_COARSE 将使用 vdso，但可能以后的 glibc 也可以优化您的函数以不调用内核（使用系统调用）”作为答案？ :) 本质上，问题是系统调用何时不是“正确的”系统调用，以及它依赖于什么......

标签： linux linux-kernel system-calls strace

【解决方案1】：

这可能是因为clock_gettime() 是优化系统调用的一部分。看看这个answer中描述的vdso机制。

【讨论】：

【解决方案2】：

回答第一个问题

来自vdso man

strace(1)、seccomp(2) 和 vDSO

使用 strace(1) 跟踪系统调用时，vDSO 导出的符号（系统调用）不会出现在跟踪输出中。这些系统调用同样对 seccomp(2) 过滤器不可见。

Answer转第二个问题：

在vDSO中，clock_gettimeofday及相关函数依赖于特定的时钟模式；见 __arch_get_hw_counter。

如果时钟模式为 VCLOCK_TSC，则无需系统调用即可读取时间，使用 RDTSC；如果是 VCLOCK_PVCLOCK 或 VCLOCK_HVCLOCK，则从特定页面读取以从管理程序中检索信息。 HPET 没有声明时钟模式，因此它以默认的 VCLOCK_NONE 结束，并且 vDSO 发出系统调用来检索时间。

确实：

在默认内核中（来自 Kubuntu）：

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

定制内核：

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

More info关于各种时钟源。特别是：

Red Hat MRG 第 2 版的文档指出，TSC 是首选时钟源，因为它的开销要低得多，但它使用 HPET 作为备用。在该环境中对 1000 万个事件计数进行的基准测试发现，TSC 耗时约 0.6 秒，HPET 耗时略多于 12 秒，ACPI 电源管理计时器耗时约 24 秒。

【讨论】：