i336_'s questions

在无数次查找如何使用gettimeofday()时，我决定这次快速深入了解 vDSO，因为我对它只有模糊的认识，并想知道是否有任何我应该注意的使用陷阱。

根据https://stackoverflow.com/questions/42622427/gettimeofday-not-using-vdso ，如果vDSO正在使用中，strace则不应显示or 。gettimeofdayclock_gettime

好吧，看起来我的 ThinkPad T400 已经坏了一段时间了：从我记事起，我就一直看到*吨*的这些电话strace。（特别是来自 QEMU。）

如果我从上述问题尝试testgtod.c（运行1000 次）：gettimeofday()

$ strace ./testgtod 2>&1 | grep clock_gettime | wc -l
1000

目前，我能在 ThinkPad 和 i3 桌面之间找到​​的唯一区别是 i3 使用 TSC，而 ThinkPad 使用 HPET，因为tsc: Marking TSC unstable due to TSC halts in idle. （想知道这是否可能是暂停/恢复的事情，但随后注意到时间戳 - 这是启动后的 1.53 秒。）T400（当前......）运行 Arch，而 i3 机器运行 Debian 9。

上面的问题也提到了dump-vdso.c。T400 上的 vDSO 对我来说看起来不错：

$ objdump -T vdso.so

vdso.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000740  w   DF .text  000000000000005e  LINUX_2.6   clock_gettime
00000000000007a0 g    DF .text  0000000000000067  LINUX_2.6   __vdso_gettimeofday
00000000000007a0  w   DF .text  0000000000000067  LINUX_2.6   gettimeofday
0000000000000810 g    DF .text  0000000000000010  LINUX_2.6   __vdso_time
0000000000000810  w   DF .text  0000000000000010  LINUX_2.6   time
0000000000000740 g    DF .text  000000000000005e  LINUX_2.6   __vdso_clock_gettime
0000000000000000 g    DO *ABS*  0000000000000000  LINUX_2.6   LINUX_2.6
0000000000000820 g    DF .text  0000000000000025  LINUX_2.6   __vdso_getcpu
0000000000000820  w   DF .text  0000000000000025  LINUX_2.6   getcpu

我发现的另一个链接https://bert-hubert.blogspot.com/2017/03/on-linux-vdso-and-clockgettime.html表示 vDSO 代码缺乏对某些计时器的支持，并将回退到系统调用，如果你使用其中之一。那篇文章来自 2017 年，https://lore.kernel.org/linux-arm-kernel/[email protected]/（2019 年 6 月）中的详细信息表明几乎所有（如果不是全部？ ) 计时器现在支持 vDSO，但无论如何，testgtod上面提到的程序称为CLOCK_REALTIME，2017 年的文章说当时支持 vDSO。

所以：我正式感到困惑:)

通过http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/阅读，我看到很多对 TSC 的引用。这篇文章并没有真正提到它，但我开始认为这可能RDTSC{,P}是一个可以从用户空间调用的非特权指令，而从 HPET 读取需要内核级访问（对硬件或计时器值）。这将完全解释系统调用回退。

顺便说一句，我的 T400 中的 Core2 P8600 确实支持tscand constant_tsc，但不支持nonstop_tsc。

_{tsc gettimeofday clock-gettime vdso hpet 都不存在，如果有更多声誉的人想要添加其中的一个或多个。}

我碰巧需要从导出的共享库符号的平面列表中找出哪个库导出了哪些符号。列表中有足够的符号（20 个左右），我不会手动交叉引用每个符号。

我发现这nm -A -D -f sysv <library-name>似乎产生了有用的输出——我可以搜索包含FUNC在第二列中也列出了地址的行。所以我对 中的所有内容都运行了这个命令/usr/lib，并将其重定向到一个文件。

令我惊讶的是，我为解析文件而编写的脚本中的健全性检查报告说存在重复的符号！经调查发现库似乎在导出重复符号？！？

我使用一些 shell 脚本验证了这一点，并且我能够将我使用的命令变成这个^{_{（技术上）}}单行：

readlink -f /lib/* /usr/lib/* \
  | grep -F .so. | sort | uniq \
  | while read x; do nm -A -D -f sysv $x; done \
  | grep FUNC | cut -d'|' -f1 | sort -g | uniq -c | sort -g \
  | sed -n '/^ \+1/!{s/^ \+[0-9]\+ \+//p}' | sed 's/ //g' \
  | tr '\n' '\v' \
  | sed ':1;s/\([^ ]\+\):\([^\v$]\+\)\v\1:/\1:\2|/g;t1' \
  | tr '\v' '\n' \
  | while IFS=: read -a x; do \
     nm -A -D -f sysv "${x[0]}" | grep ":\\(${x[1]//|/\\|}\\).*FUNC"; \
  done

上面的命令将使您的磁盘搜索一小段时间。如果需要，您可以将其分解为重定向到临时文件的块。输出也会很宽（~150 cols）。

我最初在我正在使用的 Debian Squeeze chroot 上运行原始脚本，但出于好奇，我在我的主机系统上运行了上述脚本，以查明 chroot 是否不正常。

嗯...... chroot 报告了超过 90 个重复项，但我的主机（Arch）系统显然有大约 267 个。

该命令通过 greppingnm的输出工作，因此结果有点嘈杂，但看起来像这样：

/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access|00043700|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access|000436c0|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_access_mask|000458f0|   T  |              FUNC|00000058|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size|000432a0|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size|00043260|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_max|00044ff0|   T  |              FUNC|0000003c|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_max|00045030|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_min|000453c0|   T  |              FUNC|00000037|     |.text
/usr/lib/libasound.so.2.0.0:snd_pcm_hw_params_get_buffer_size_min|00045380|   T  |              FUNC|0000003c|     |.text

注意每个符号有两个。地址是不同的，是的，但是......我认为动态链接是通过符号名称工作的，就是这样。（如果您在上面的列表中向右滚动）这些符号都是类型FUNC并且来自该.text部分，这使我更加困惑。

我发布这篇文章是为了了解这里的引擎盖下正在发生什么有趣的魔法。（因为我的系统正在工作......）

如果有人有任何好主意，我可以转储大约 600 行文本 - Pastebin 似乎不再流行，而且我不使用 GitHub - 我很乐意分享完整的输出。